Hard-coded Strings and the Xojo Compiler

  1. 2 weeks ago

    Scott C

    Sep 4 Pre-Release Testers, Xojo Pro Vancouver, Canada

    Hello,

    I know the advantages of Constants, whether entered in the Constants Editor and/or localized. As well as the Const keyword. The main advantages being that you can rely on the values, because they can't be changed.

    But if a "mutable" type is declared as a constant (if such a thing can happen?), does the Xojo compiler provide some optimization?

    Also, what about when embedding a hard-coded string (that won't be changed programmatically and only occurs once as a unique value) in something like:

    Dim myNodeList As XmlNodeList = rootNode.Xql("/root/node/someList")

    Is there any benefit to declaring that hard-coded string first as a constant, or does the compiler know that hard-code values (like the case above) should be treated like constants?

    I tried searching the docs and the forum, but couldn't find clarity. I hope my question makes sense. Thanks.

    I just created a test app,

    Dim a As String
    Dim b As String
    Dim c As String
    Dim d As String
    Dim e As String
    a="Hello World"
    b="Hello World"
    c="Hello World"
    d="Hello World"
    e="Hello World"
    .... the above 5 lines repeated 400 times

    and the string "Hello World" appeared in the compile code ONE time

  2. Dave S

    Sep 4 San Diego, California USA

    I do not know about the Xojo compiler, but with what little experience I have with others (including a few I've written myself). Most "quoted" strings are gathered into an internal table and then referenced by pointer. So if you had "Hello World" 1000 times through out your code, it would compile to ONE instance of the string, and 1000 instances of a pointer.

    Again... I do not know if this is how Xojo does it, but it should be simple to determine. Create "Hello World" a 1000 times, compile it, then see what is in the compiled code :)

  3. Dave S

    Sep 4 Answer San Diego, California USA

    I just created a test app,

    Dim a As String
    Dim b As String
    Dim c As String
    Dim d As String
    Dim e As String
    a="Hello World"
    b="Hello World"
    c="Hello World"
    d="Hello World"
    e="Hello World"
    .... the above 5 lines repeated 400 times

    and the string "Hello World" appeared in the compile code ONE time

  4. Norman P

    Sep 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Scott C But if a "mutable" type is declared as a constant (if such a thing can happen?), does the Xojo compiler provide some optimization?

    You mean like

        const foo as string = "123" 

    or something else ?

    @Scott C Is there any benefit to declaring that hard-coded string first as a constant, or does the compiler know that hard-code values (like the case above) should be treated like constants?

    Actually constants are more like literals :P
    Basically a constant is short hand for writing the literal value everywhere

  5. Scott C

    Sep 4 Pre-Release Testers, Xojo Pro Vancouver, Canada

    @Norman P You mean like

    const foo as string = "123"

    or something else ?

    Sorry, yes I was thinking more along the line of how a Class can be inherently mutable, but declared a constant. Like how Java would do it using the final keyword. But after a little further searching & testing, Xojo doesn't appear to allow such a thing, either in the Constants Editor or with the Const keyword (throws a syntax error).

    From what I've read, although it's not explicitly stated anywhere I found so far, it appears that nearly all built-in Xojo data-types are immutable (e.g., String, Integer, Color, etc.). The exceptions apparently being some Bitmap image types, the Xojo.Core.Dictionary and Xojo.Core.MutableMemoryBlock.

    In summary, because Xojo types are mostly all immutable, and as you say Norman, constants are more like literals, I guess the peak of optimization is automatically providing a pointer for each hard-coded unique value to a single place-holder (as demonstrated by Dave) during compile-time? Hopefully I go that right and it make sense?

    I can live with that. Obviously I'm using Localized Strings for all visible text and other constants for repeated logical references.

    But I wanted to know how far I should go with trying to optimize my code to avoid duplicate hard-coded values like Strings in other non-visible areas.

    Thank you Norman and Dave both.

  6. Dave S

    Sep 4 San Diego, California USA

    just for curioiusty... I duplicated the above test program in Swift (only had to change the DIM to VAR)
    same results... "HELLO WORLD" appeared once.... but what was also interesting

    in Xojo the compiled module was 1.6M but in Swift it was a mere 200K (iOS) and 142K (macOS)
    these were the "exe" sizes, not the entire bundle

  7. Norman P

    Sep 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Scott C Sorry, yes I was thinking more along the line of how a Class can be inherently mutable, but declared a constant. Like how Java would do it using the final keyword. But after a little further searching & testing, Xojo doesn't appear to allow such a thing, either in the Constants Editor or with the Const keyword (throws a syntax error).

    No Xojo has not support for FINAL in pretty much any form
    Sadly :(
    Feedback Case #18762

    @Scott C From what I've read, although it's not explicitly stated anywhere I found so far, it appears that nearly all built-in Xojo data-types are immutable (e.g., String, Integer, Color, etc.). The exceptions apparently being some Bitmap image types, the Xojo.Core.Dictionary and Xojo.Core.MutableMemoryBlock.

    String is the only one I can think of
    Most other intrinsic types are directly mutable

    @Scott C In summary, because Xojo types are mostly all immutable, and as you say Norman, constants are more like literals, I guess the peak of optimization is automatically providing a pointer for each hard-coded unique value to a single place-holder (as demonstrated by Dave) during compile-time? Hopefully I go that right and it make sense?

    Strings being immutable common ones can be merged and then any time you try to mutate one you get a new string

  8. Scott C

    Sep 4 Pre-Release Testers, Xojo Pro Vancouver, Canada

    @Norman P String is the only one I can think of
    Most other intrinsic types are directly mutable

    Oh, okay that's interesting.

    I know with immutable types, generally, that although the original values are "unchangeable", the compiled app (of whatever language) will automatically perform copy and instantiation operations on the fly (behind the scene, so-to-speak) to give the "appearance" of variable manipulation. But that kind of manipulation typically can come with some overhead.

    For example, in C# a string is immutable, but StringBuilder is mutable, so I often used StringBuilder over string, when I knew the value would change dynamically, because merging string values to a mutable object was more performant and efficient than doing the same to an immutable object.

    But for the opposite reason, when I know a mutable (changeable value) will not change, is there a benefit to declaring a mutable type as a constant, like:

    Const specialErrorCode As UInt8 = 100

    Does the Xojo compiler know not to provide that "behind the scene" support for potential variable manipulation as an optimization benefit?

    If I'm babbling and not making sense, just tell me. I'm a self-taught developer, so I'm not necessarily up on the correct lingo I should be using here.

    My goal was just to find what is more efficient in the long run, as I build apps with Xojo.

    Having been a web developer for so many years, I've seen the benefit of trying to squeeze every once of efficiency out of my code (where it's practical), as good coding practice.

    Thank you for your time guys :-)

  9. Norman P

    Sep 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Scott C Oh, okay that's interesting.

    I know with immutable types, generally, that although the original values are "unchangeable", the compiled app (of whatever language) will automatically perform copy and instantiation operations on the fly (behind the scene, so-to-speak) to give the "appearance" of variable manipulation. But that kind of manipulation typically can come with some overhead.

    Ints doubles etc are the low level IEEE types directly exposed
    No magic
    Twiddle their bits pretty much all you want
    There is no "instantiation" for them

    Strings are the only intrinsic type that is a reference type and imutable

    Everything else from the frameworks that you have to declare & instantiate using NEW is a reference type

    @Scott C For example, in C# a string is immutable, but StringBuilder is mutable, so I often used StringBuilder over string, when I knew the value would change dynamically, because merging string values to a mutable object was more performant and efficient than doing the same to an immutable object.

    Xojo is not C# :P
    There is no stringbuilder although I think others have created such a thing as string concatenation can be slow because of how strings work
    In many cases, esp if you concatenate large strings, its actually faster to create a string array, append all the bits then use JOIN to create the string

    @Scott C But for the opposite reason, when I know a mutable (changeable value) will not change, is there a benefit to declaring a mutable type as a constant, like:

    Const specialErrorCode As UInt8 = 100

    I'm not certain there is any specific advantage
    That said note that only when you declare CONSTS inline in code can you assign a specific type like that :(

    @Scott C Does the Xojo compiler know not to provide that "behind the scene" support for potential variable manipulation as an optimization benefit?

    I'm not 100% sure what you mean by this ?

    @Scott C Having been a web developer for so many years, I've seen the benefit of trying to squeeze every once of efficiency out of my code (where it's practical), as good coding practice.

    Write intelligible code
    Benchmark and test for any speed issues and THEN optimize
    Trying to optimize as you write is usually a false saving and often focuses on areas that arent that important
    Often the biggest win is switching algorithms - not tweaking the use of specific types here and there

  10. Tim H

    Sep 4 Pre-Release Testers Portland, OR USA

    @Scott C Const specialErrorCode As UInt8 = 100

    The value of specialErrorCode cannot be changed. But the value of whatever variable you assign it to can, of course.

    dim i as Uint8
    i  = specialErrorCode    // 100
    i = i + 1    // 101
    specialErrorCode = 99    // compile error
  11. Garry P

    Sep 4 Pre-Release Testers, Xojo Pro Europe (Torquay, UK)

    @Dave S just for curioiusty... I duplicated the above test program in Swift (only had to change the DIM to VAR)
    same results... "HELLO WORLD" appeared once.... but what was also interesting

    in Xojo the compiled module was 1.6M but in Swift it was a mere 200K (iOS) and 142K (macOS)
    these were the "exe" sizes, not the entire bundle

    Not a fair comparison - Swift executables don’t need to include the runtime frameworks on macOS as they’re bundled with the OS. Xojo apps need to include the Xojo runtime.

  12. Dave S

    Sep 4 San Diego, California USA

    @Garry P Not a fair comparison -

    just pointing out a fact... not saying it was or was not "fair"...

    but then... why can other "compilers" (including dot Net) use the OS frameworks, and Xojo (cannot or does not)?

  13. Norman P

    Sep 4 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    If Xojo only generated code for macOS then Xojo could probably just use the native SDK directly as well
    But it doesnt
    So it inserts a layer in between to insulate you forom much of that difference between platforms
    Thats the Xojo framework

  14. Garry P

    Sep 5 Pre-Release Testers, Xojo Pro Europe (Torquay, UK)

    And it's why we love it :)

  15. Michael D

    Sep 5 Pre-Release Testers, Xojo Pro

    @Garry P Not a fair comparison - Swift executables don’t need to include the runtime frameworks on macOS as they’re bundled with the OS. Xojo apps need to include the Xojo runtime.

    This is not true in all cases - I think only Swift 5 allows this, and only on newer OSs.
    See https://swift.org/blog/abi-stability-and-apple/

  16. Garry P

    Sep 5 Pre-Release Testers, Xojo Pro Europe (Torquay, UK)

    It’s a reasonable statement since Swift’s development is such that it’s difficult to not use the latest version. Similarly, the overwhelming majority of macOS users are on the latest version or the preceding one.

or Sign Up to reply!