Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmarks vs 5.20 #101

Open
schwern opened this issue Mar 26, 2014 · 0 comments
Open

Benchmarks vs 5.20 #101

schwern opened this issue Mar 26, 2014 · 0 comments

Comments

@schwern
Copy link
Contributor

schwern commented Mar 26, 2014

CC: @rjbs (I'd CC Zefram but I don't know his Github account)

Howdy folks. I did some benchmarking of MS vs 5.19.10 and thought you might want to know how it turned out.

At runtime, ie. executing functions with signatures, we're about the same. This makes sense since both implementations should compile down to roughly the same code with roughly the same features. Here's the runtime benchmark.

At compile time we're immensely slower. 40x slower. This, too, is entirely in line with predictions as we're working in Perl and PPI and 5.20 is working in C with the parser itself. Here's the compile time benchmark. I tried to make it represent realistic scales in terms of number of subroutines in a production Perl project.

My conclusions...

For persistent programs (ie. web stuff) Method::Signatures and 5.20 signatures will perform about the same. This makes Method::Signatures very handy as a backwards compatibility library. And we can advertise that MS can be used as an extension to 5.20 signatures without runtime performance impact.

5.20 signatures are performing well. (I had a brief scare when the first version of the compile benchmark said we were faster than builtin, indicating something very wrong with 5.20, but then realized I'd used sub instead of func for Method::Signatures).

We're performing well at runtime. I am a bit surprised 5.20 didn't edge us out.

It may be useful for MS under 5.20 to scan signatures, determine if they're using the 5.20 subset, and take advantage of the 5.20 signature feature. That will save time only if MS can determine if a signature is in the 5.20 subset faster than it takes MS to compile it itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant