That was my guess too. 
Whatâs the difference between, say, Script and ScriptB? Just a second run?
ScriptB is using the binary version of ReplaceAll.
Ah. If the goal is to just time the loop, you could have done something trivial like i = i + i - i in the heart of the loop. I donât know for certain, of course, but I think that would keep the compiler from stripping that code.
I had tried dimming another integer variable j and j= i in the loop but that had no effect. And as I was mostly interested in speeding up string processing Â
Got it. FYI, Iâd expect that to be stripped too because you didnât actually do anything with j. It depends on how clever the new optimizations are, I guess.
that depends on what optimization level you used
My tests were done with âbestâ.
I believe XojoScript is short cutting the loop even with simple code designed to prevent that (i.e. i = i + i - i; x = x + 1). Put some real math in there that doesnât have an obvious short cut but also does not dominate the test and you will see loops are much faster.
I think your 2nd test is dominated by ReplaceAll.
Of course this illustrates that LVM is not magic. The performance of some tasks depends on operations which are outside of LVM and/or already optimized (i.e. a library compiled from C/C++/obj.C). But LVM will really help with some stuff.
From the outset I really wanted to reply with something like
just for fun to see who called that sat out for all the obvious incorrectness of it.
I love benchmarks for the same reasons
Now look at Feedback item #33168, run the Cocoa test driver, then apologize to the Windows framework. 
I love this thread. It is quite lively and full of posts about code that does nothing. Entirely bug free
Iâm in the process of moving one of your back-end applications from XOJO to B4J its a REST based API cloud service as we grew the XOJO version just could not keep up with the request loads it was getting (could have been our code), with b4j we are using the JETTY engine which is able to handle 1,400 requests per second now on a single server. Its also now a 64bit app vs the 32bit. Also been playing with the JavaFX Scene build lots of much needed GUI elements on that end. As much as I love XOJO I have still not gotten use to the new GUI editor, finding my self more frustrated with copy/paste issues etc⊠Iâm sadly seriously linking about moving to Java for future cross-platform development.
What type of load were you taking? Also what kind of horse power on the server you hosted it at?
We developed a HTTP based web server which acts as a REST base API service for our VOIP and related applications platform. We had 4 servers running each with 4GIgs RAM with 2vpus connected via a load balancer with HTTPS on the load balancer end. We are getting around 700 to 800 requests persecond during peak working hours Mon-Friday (about 4 hours each day). We found we could handle about 158 requests per second on each server. What pointed the problem is are monitoring system was seeing long delays in requests being processed sometimes up to a minute. Now that we are using jetty we are down to 2 servers in the load balancer with lots of room for growth. I think the core of the issue with our code in XOJO has to do with the lack of ability to create threads pools for processing requests. We used Apaches âabâ benchmarking too to load test the two.
@Jordan Morris Yes, B4J looks very promising, The examples connecting with B4A also show great potential. Havenât found much time to experiment with it yet, but definitely will. Erel is doing some great work on it. Being 100% free is also plus
Thanks! Thatâs valuable information for the rest of us, what type of loads can we expect.
Daveâs test:
IDE 24.38 - 25.9 seconds
compiled 1.58 - 1.66 seconds
Windows 8.1 pro 64-bits
AMD Phenom II x6 1090T 3.2Ghz (about 2 years old $600 new price then)
For UI or back end server work ?
For server side work Java is pretty decent (verbose but there are some huge class libraries)
But for UI work  blech ! It still doesnât make native looking or native behaving apps on any platform
Thatâs why Java never became the world-beater it was hyped as.
[quote=88334:@Norman Palardy]
But for UI work Â
blech ! It still doesnât make native looking or native behaving apps on any platform[/quote]
Right now just back-end stuff, but Iâm exploring the JavaFX GUI stuff really like that you can make application skins, they have one for each OS platform so that might help with the look aspect of the GUI. JavaFX also has a lot of the same controls that I miss when moving from Visual Studio to RB/Xojo.