Followup: https://github.com/ruby/ruby/pull/19537 Similarly, by adding a fastpath for `String` in `opt_new` we can peek in the stack to pre-allocate a string of the right size. Additionally, by moving `String#initialize` in `string.rb`...byroot (Jean Boussier)
String keys are about as common as symbol ones, and can benefit from the same optimization because Ruby hashes directly hash and compare bare strings without calling `#hash` nor `#eql?` just like Symbols. However that only applies if ke...byroot (Jean Boussier)
A bug report has been filed [Bug #22539] and backport requested for 4.0. Closing this, and I'll merge the `String.new` fastpath soon.byroot (Jean Boussier)
> BTW, I think this should be Bug, not Feature since it's an unintentional incompatibility. The bug should be a different ticket. I'll open it. byroot (Jean Boussier)
> refinements applying to initialize seems an accidental side-effect of opt_new inlining the call to initialize in the bytecode and we should fix it. Indeed. > ... I assume it means instead of generating a `send` instruction, we ne...byroot (Jean Boussier)
Since the introduction of `opt_new` in [Feature #21254], if a class's `initialize` method is refined, the refined version is called. That's not the case when disabling compiler optimizations, or calling `new` with `send`. After put...byroot (Jean Boussier)
I have a patch for this: https://github.com/ruby/ruby/pull/19844, but I'm not 100% certain it doesn't regress this optimization, and based on the handful of failing ZJIT tests, it looks like it does generate different code sometimes. ...byroot (Jean Boussier)
If the left hand side is a Symbol or bare String, it doesn't make sense to gate the optimization to the right hand side being of the same type. If the type differs, we can directly return.byroot (Jean Boussier)