Very glad to read that - thanks for posting it.
I think we owe a debt of gratitude there for the dev team-community partnership between long-time user Jacque Gay and RunRev engineer Ali Lloyd.
To help identify any performance differences between 7.0 and earlier versions, many of us participated in a project led by Malte to craft specific isolated benchmarks. Interesting as that project was, the results weren't actionable since many of the underlying methods for so many aspects of engine behavior operate very differently in v7 than in earlier versions.
So instead RunRev's Peter Brett put out a call for any projects where speed is a noticeable issue under v7, and Jacque submitted one of hers. Apparently in the course of reviewing her stack Ali discovered a significant opportunity for boosting throughput, and jumped on it.
Another earlier change may also play a role here. It's less significant in terms of per-iteration benefit, but at least as pervasive: copy-on-write-only.
In earlier versions, when passing values to handlers the value was copied unless you'd specified that it should be handled by reference using "@", e.g.:
- Code: Select all
on SomeHandler @SomeParam
This meant a relatively expensive allocation and copy for each value passed to every handler.
In v7 values are always passed by reference initially, which means copying just the 4-byte address rather than the entire value itself.
But passing by reference is very different from passing by value: by value means you're working on a copy of the data, so the original is unaltered, but by reference the original data is used.
When you want to operate on the original data that's a good thing, but if you want the handler to alter the copy and leave the original alone, how does this new scheme handle that?
It detects when an operation will alter the value passed in, and unless it was explicitly declared as "by reference" with "@" in the argument list, at that time it will copy the data so the handler leaves the original alone.
If you think about the number of times we have handler that read data passed to them without altering it, you can begin to appreciate the value this change has for overall performance.
Coupled with the great work Ali's done with the issue Jaqcue found, it looks like v7 is shaping up very nicely, well on its way to being not only the most feature-rich version of LC ever, but the most bug-free and in many cases the most performant.