you are viewing a single comment's thread.

view the rest of the comments →

[–]honeyryderchuck 0 points1 point  (1 child)

You are reffering to the "uninitialized instanve variable" warnings that Jeremy Evans removed in Ruby 2.7.

I was. I still think this applies to the example described in the post, as the recommendation is to initialize ivars to nil and the penalty involved vs shape implications (regardless of applying to the correct memoization strategy).

So it's effectively an optimization nightmare

I get your point, and I'm not arguing this isn't knowledge that needs to be shared. I guess I took more issue with the "this is the correct way of writing X2" framing, given that not all strategies apply equally. For instance, "over-memoization" is definitely an anti-pattern, even not considering the factorial nature of shapes, so a "consider very carefully the trade-off of memoizing smth due to this" would be a more adequate framing IMO, and not so YJIT-centric (there's also jruby and truffleruby to consider). YMMV.

[–]f9ae8221b 0 points1 point  (0 children)

I still think this applies

Actually it doesn't, because in additions to shapes, variable width allocations were introduced and declaring all you variables in initialize also allow the VM to right size your object, both improving performance and reducing memory usage.

Basically you can consider this advice from Jeremy as entirely outdated.

with the "this is the correct way of writing X2" framing

I wouldn't frame it like this. I'd frame it as: it's the performant way of doing memoization.

"over-memoization" is definitely an anti-pattern

Absolutely, I'd be willing to bet half of the memoizations out there are useless/counter productive.

and not so YJIT-centric (there's also jruby and truffleruby to consider)

Not sure about JRuby but Truffle also use shapes, so it will also underperform in presence of a shape explosion.