-
Notifications
You must be signed in to change notification settings - Fork 13
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
Shapes: objects with lots of ivars are always too complex #542
Comments
And the 3.2.2 shape list to compare:
|
Ok, after digging a bit it's because we run into ruby#7188, initially it was set at 50, now it's at 80. I'll try to figure out the reasoning. |
Ah, it was in response to https://bugs.ruby-lang.org/issues/19334. |
So what happened with the idea of keeping an |
AFAIK it just hasn't been prioritized yet. I implemented a functional red black tree for doing the lookups, but we're not sure if the memory usage is worth the speed. IOW, are inline cache misses frequent enough that it's a bottleneck? Especially with YJIT enabled. My red-black tree implementation is here. I'll rebase it against master so we can try again. |
I don't have actual production number. I was working from micro-benchmark, e.g. trying to eyeball the performance impact of the rather common "memoization" pattern. It would be nice to get some production statistics, but we'd need a modified ruby build. |
On
3.2.2
:On ruby-head:
Note how the object is marked as
too_complex
even though ivars were always defined in a consistent order.Here's the full shape list:
cc @tenderlove @jemmaissroff
The text was updated successfully, but these errors were encountered: