[Updated]
(2024-06-10 11:13 JST) update to v5.40 benchmarked result GitHub - kfly8/bench-perl-class-builder at v5.40
(2023-08-22 21:30...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the benchmarks. Your Moose case for constructor is flawed, as you didn't make the class meta immutable: metacpan.org/dist/Moose/view/lib/M...
Also, I would suggest having at least a couple of fields in your class. Having just one may favor some simpler solutions which may not scale well. In my own benchmarks it seemed like Moo constructor did not scale as good as Moose one, while being faster for super simple cases.
Thanks for your comment!
I agree that Moose (and also Mouse) would be better if they were immutable.
And you are right, I think the benchmark would be better if it handled cases where the fields are complex.
I would be happy to send me a pull request!
Thanks for your pull requests! I updated this post and repository.
Something to keep in mind with the field access benchmarks is that the very design of
Object::Pad
and the core class system offers direct access to the fields of the object to the class's own methods, as simple lexicals. Code inside methods does not have to use the accessors just to see or modify those values. This is a feature unique to those two systems.Therefore, in real-world code scenarios, the faster more-direct access these provide means that overall code can run faster in a way that simple benchmarks "from outside the class" such as your
bench-field.pl
do not manage to capture. It would not be easily possible to write a "universal" test case in the same style as your scripts to demonstrate this, exactly because of this unique ability.As an example, consider this silly class:
The
->as_css
method here has direct access to the$red
,$green
and$blue
lexicals, and so invoking that would only involve one actual method call at runtime. Whereas, this class based on any of the other systems would need code something like:and thus any call to the outer method would involve three inner calls, a total of four. Once you get into real-world scenarios with code that contains real-world behaviour, the cost of all these little inner
$self->field
accessor calls quickly adds up and overtakes the original cost of the outside method call or even the object constructor.Perhaps you could add a new category of benchmark, one that constructs an object with a few nontrivial fields and then performs a calculation method based on the values of those fields - feel free to steal my example code above if it helps. I'd be very interested to see benchmarks of that kind of case too.
Thanks for your kind comments!
I will try the new benchmark case!
It's interesting to see Mouse still leading the pack of the Moose compatible crowd. We switched to it a few years ago after benchmarking, and we've kept it even though Moo became more popular. It even manages to pull a win over the current version of
class
, but the latter is sure looking good otherwise, especially for something newly added to core!As you say, by far the best performing accessor was Mouse. I think the difference is whether the accessor works with XS or not. class feature will be adding a :reader modifier in the future that will make the accessor live, and I will try to benchmark it again when that is added.
Hey, really nicely done! Hope we can keep this benchmark alive as long as possible!
One suggestion: it would be really nice to keep a "history" graph to follow core class enhancements in future Perl versions. AFAIK only the MVP was introduced to the core, but many optimizations are still to be done, including (as you mentioned in one of your comments)
:reader
and:writer
accessors and, possibly, many other low-level object handling optimizations. So I really expect to see core class feature numbers to decrease, but who knows right? :DThank you for your comment!
You are right, it would be nice to keep a history! I look forward to following future Perl updates.
Very nice!
Thanks for the update.
Seems the implementation is catching up to blessed hash references.
What about inside out objects classes such as Class:Std, DIOS etc ?
Thank you for your comment! I would be happy if you could send me a pull request!