I am just investigating using Xojo to upgrade a lot of VB6 code.
In doing so I am researching the corner cases and gotcha’s I expect to encounter along the way.
As a start, I have a simple piece of VB6 code shown below that takes roughly 50 seconds to execute on my computer in VB6 both compiled and in debug.
I do not have a Xojo license yet so I can only test it in debug mode but in Xojo it takes almost 80 seconds - it’s much slower than VB6. I was a bit surprised by this.
While this may not be the best implementation, it is still a valid performance test.
Can anybody shed any light on this? Can I expect the compiled Xojo exe to perform differently?
Thanks. Jeff
dim i as integer
dim j as integer
dim kk as integer
dim sTagsArray() as string
Dim sNewString As String
Dim myTestString As String
myTestString = “1230,345,456,6780,789,901,1240,346,457,5680,679,345,4560,678,789,9010,124,346,4570,568,679,”
For i = 0 To 10000000
sTagsArray = Split(myTestString, “,”)
kk = UBound(sTagsArray)
For j = 0 To kk
sNewString = sTagsArray(j)
Next j
Next i
Yes. The debugger adds significant overhead. The compiled app will be faster. Depending on which optimization option you choose, it may be much faster.
To me, this looks like an unrealistic test example. I spent about two years converting enough of an application (these days it would be a webapp, I suppose) before I could satisfy myself that Xojo could do the job. Only then did I decide it could, and start optimising some of the slow bits.
If you are splitting on ASCII characters, and your strings are ASCII or UTF8, in older versions of Xojo, one should use SplitB() rather than Split(). One of the great things about UTF8 is that you are guaranteed that there will never be a non-ASCII character that has the same code point.
However, I just tested it, and found this result (Xojo 2023 R4, built app, Intel core i9, macOS Ventura):
36 seconds Split()
36 seconds SplitB()
I was surprised to see no change - I’m pretty sure in earlier versions of Xojo the Split vs. SplitB difference was big. Did Xojo optimize Split() at some point?
Xojo does and checks a number of things under the hood each time you loop. There are pragmas that can turn some of them off, which can also give a significant speed boost (though I don’t know if it applies to debug mode)
For most use cases, debug performance is significantly less critical than that of the compiled app…
I suspect that is why Xojo has not put more emphasis on optimizing debugging execute speed.
That said, given that Xojo is a try before you buy product, and you can only try it in debug mode, it seems to me they might want to pay more attention to that, as well as performance in general.
Can you give some details on your machine spec?
Processor, RAM , harddisk type so that maybe we can do test with XOJO latest version on same machine spec.
However, coming from VB6 community to xojo almost 30 years ago, i think you should give XOJO a chance. It offers many flexibility that VB6 dont have.
I want to thank all of you for your input. This was a test using Split function in every iteration (as if reading from a file but without muddling the results with file i/o) and then accessing every element.
I am glad to see that the forum is alive and well. This means a lot.
It’s also worth noting that by default, VB6 is using ASCII strings while Xojo uses UTF-8 strings. This gives Xojo more work to do when splitting them, but makes the strings much more versatile and more appropriate for modern computing experiences.
I think the actual performance of the Split-Function in Xojo is an interesting observation. It seems a bit slow to me me, because the sample code is about 4x faster in Java, for example. Not sure why. Java also processes Unicode Strings. I tried building a Split-Function in Xojo based on MemoryBlocks, it’s even slower than the Xojo-Split-Function.
After re-reading Mike’s post: May it’s not the Split-Function at all, but the memory management or something else?