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

Examine the falcon backport patches for improvements we could apply to JRuby #412

Closed
headius opened this issue Nov 26, 2012 · 5 comments
Closed
Labels
Milestone

Comments

@headius
Copy link
Member

headius commented Nov 26, 2012

Several perf improvements from Ruby 2.0.0 have been backported to 1.9.3 by "falcon". They're enumerated here: https://gist.github.com/4136373

Some of these may be applicable to JRuby, such as Hash perf improvements and "Array as a queue" perf improvements. We should examine the list to see what we can duplicate.

@headius headius changed the title Example the falcon backport patches for improvements we could apply to JRuby Examine the falcon backport patches for improvements we could apply to JRuby Apr 5, 2016
@headius
Copy link
Member Author

headius commented Apr 5, 2016

@funny-falcon enumerated the patches separately here: https://gist.github.com/funny-falcon/4136519

There are five patches (the sixth combines 2 and 3):

  1. backport-speedup-require - may still be relevant to us but in order to support it we'd likely need to examine and port MRI logic that enables cached expanded load path.
  2. st_opt - performance improvements to Hash, specifically compacting of small hashes, slab allocation of items, and "ultrapacking" of single-element hashes. We currently allocate single-bucket hashes for small literal hashes. Slab allocation probably doesn't apply to JRuby. The small hash compacting may be worth looking into.
  3. sparse_array - a new structure for method/constant/ivar lookup. Does not apply to JRuby.
  4. ary_queue - make arrays more suitable as queues via push/shift improvements. May apply to JRuby.
  5. backport-gc - COW-friendly GC. Does not apply to JRuby.

@headius
Copy link
Member Author

headius commented Apr 5, 2016

st_opt contains one optimization that might be slightly worthwhile; specifically, it adds a separate "packed" hash entry struct that does not include insertion-ordered traversal fields. However, this would represent a savings in JRuby of only three reference fields (24 bytes at most, but usually less) and only for single-element hashes. I don't believe the optimization is worth it right now, and it really won't be if we get keyword arguments to be object-free in the future (since most single-element hashes will likely be from keyword args).

@headius
Copy link
Member Author

headius commented Apr 5, 2016

ary_queue's main optimization appears to be using MEMMOVE to slide array contents around when there's nobody sharing the backing store. This does not really apply to JRuby, since any MEMMOVE equivalent will require at least a memory copy, and at worst a second array allocation.

I will look to see if moving elements would be a valuable optimization for our push/shift impls.

@headius
Copy link
Member Author

headius commented Apr 5, 2016

I believe it's not worth the more complicated metrics and special-case logic required to use copying to shift elements around without allocating a new array store. A heavy push/shift benchmark is also over 3x faster in JRuby right now.

Closing, since none of these optimizations appear to apply to JRuby anymore. The load path optimization is known to be missing in JRuby and is tracked by other bugs.

@headius headius closed this as completed Apr 5, 2016
@headius headius added this to the Won't Fix milestone Apr 5, 2016
@funny-falcon
Copy link

There are couple of alternative Hash implementations this spring https://bugs.ruby-lang.org/issues/12142
One is mine, other is Vladimir Mararov's.

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

No branches or pull requests

2 participants