Charles Oliver Nutter created JRUBY-6330:
--------------------------------------------
Summary: Performance degradation in Time.strptime with
invokedynamic
Key: JRUBY-6330
URL: https://jira.codehaus.org/browse/JRUBY-6330
Project: JRuby
Issue Type: Bug
Components: Compiler, Performance
Affects Versions: JRuby 1.7
Reporter: Charles Oliver Nutter
There appears to be a rather severe degradation in performance on the
Ruby-based Time.strptime when running on JRuby master with invokedynamic.
{noformat}
Java 7 without invokedynamic:
Time.strptime 65.929000 0.000000 65.929000 ( 65.930000)
Java 7 with invokedynamic:
Time.strptime 196.221000 0.000000 196.221000 (196.221000)
{noformat}
I investigated a bit. The offending method is eventually Date._strptime_i in
date/format.rb. It's a pretty dreadful method...very large, with a giant
case/when statement with String cases. It appears that it is actually compiled
by the JVM JIT, but it's so large I'm sure many of the dynamic calls are not
inlining. I suspect that because non-inlined invokedynamic calls are still very
slow, performance suffers.
This lends some weight to building in a tiered failover that would limit
invokedynamic use to smaller methods, failing over to normal CallSite
invocation and eventually full interpretation. The compiled version using our
simpler inline caching logic manages to perform around 3x faster...a vast
margin.
The benchmark is here: https://gist.github.com/1586648
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
