Thanks for filing the bug report, Ax.
RE versions: I generally use the latest build for day-to-day work to make any bug reports more actionable, with deployments like standalones and servers limited to Stable to minimize regressions.
RE shared hosts: I use shared myself for many things, but given that an average machine at a profitable hosting company will have between 200 and 300 other tenants running on it, the "noisy neighbor" problem makes benchmarking problematic. I'll see if I can get some time to run this test on a VPS soon.
RE PHP7+ speed: For most of the history of server-side scripting, PHP, Perl, Python, MetaCard/LiveCode all ran about the same, with a few things a bit faster in one than the other. Then PHP 7 happened. Total game changer. Much has been written about it, but in short no other scripting language in common use even comes close to it for raw speed. They did some great work.
This chart shows relative performance of a wide range of server languages:
That's from this article, a worthy read:
What Programming Language Should I Learn First in 2021?
If speed is the only consideration, even better than PHP would be Node.js. And even better than Node would be Go. And faster than Go is machine code compiled from C.
Performance is always important, and on servers even more so. But does it override all other considerations when choosing a language to develop a given project in?
Not for the inventor of the Rails framework, who found Ruby fast enough when he first wrote Rails, and shared some thoughts on that a few years ago:
Ruby has been fast enough for 13 years.
Security is also a consideration, and while I would never advocate "security by obscurity", PHP is a
high-value target walking around dark alleys with a target on its back. Proportionately, PHP gets more attention from organized crime than it does from recruiters.
I won't blame PHP for being popular. It's a fine language. And so is Ruby. And Python. And LiveCode.
Indeed, LiveCode's chunk expressions make it a natural fit for server work, where most of what we do is parsing and concatenating text. For myself, the ability to deploy robust code quickly is a high priority. I'd much rather shave two weeks off my development schedule than 20 milliseconds off a response time.
Where performance is critical, shared hosting is a bigger impediment than nearly any differences between scripting languages. And far less predictable.
But I don't think shared hosting is necessarily a bad thing. I use it myself where it's a good fit.
Shared hosting is fast enough for many millions of sites.
And so is LiveCode.
The optimizations that pushed PHP 7 ahead of most other scripting languages didn't mean Ruby or Python or anything else went away. We have many languages to choose from because each brings something uniquely valuable to the table.
LiveCode has a place among the great scripting languages of our time. Use what works for you.
And all that said, benchmarks that include errors aren't very helpful in assessing performance. And when those are run on a shared host, even less so.
Any comparison of nearly anything that isn't Node or Go will measure slower than PHP 7. But whether that makes any difference in real-world performance depends on the app. And where real-world performance matters enough to worry about, it isn't happening on a shared host.
Let's get those errors sorted. Doesn't matter how fast something is if it isn't producing a reliable result. Your bug report on that is a great first step. Thanks.