Hard-coded Strings and the Xojo Compiler

General
1

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.

2

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 :slight_smile:

3

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

You mean like

    const foo as string = "123"

or something else ?

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

5

[quote=452778:@Norman Palardy]You mean like

const foo as string = "123"

or something else ?[/quote]

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

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

[quote=452797:@Scott Cadillac]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).
[/quote]
No Xojo has not support for FINAL in pretty much any form
Sadly :frowning:
<https://xojo.com/issue/18762>

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

[quote=452797:@Scott Cadillac]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?
[/quote]
Strings being immutable common ones can be merged and then any time you try to mutate one you get a new string

8

[quote=452800:@Norman Palardy]String is the only one I can think of
Most other intrinsic types are directly mutable[/quote]

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 :slight_smile:

9

[quote=452809:@Scott Cadillac]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.
[/quote]
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

Xojo is not C# :stuck_out_tongue:
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

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 :frowning:

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

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

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

[quote=452799:@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[/quote]
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

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

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

And it’s why we love it :slight_smile:

15

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

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.