The Range Marshal compat dumper would allocate an Object with no size information, hence get a 32B slot with enough space for 2 ivars, then insert 3 ivars causing it to spill. This isn't a big problem, but somewhat shows that the interf...byroot (Jean Boussier)
If `ruby2_keywords` is deprecated, I'll also likely drop support for 2.x rubies in a bunch of gems. I suppose there isn't much reason to keep it, for a while `ruby2_keywords` was the most efficient way to do blind delegation, but sinc...byroot (Jean Boussier)
Based on the data you've provided, I'm pretty convinced that bumping the limit to at least ~128B would make a lot of sense. We could also have a different limit depending on the status of the source string. If the source string is alr...byroot (Jean Boussier)
THe downside is that we now always reserve one 8B reference for the IMEMO/fields, even for structs that never have any ivars. But it is an acceptable tradeoff given that ivars on structs aren't rare. Co-Authored-By: John Hawthorn <john...byroot (Jean Boussier)
It is currentyl fairly slow as it rely on a Regexp match, which isn't very fast an allocates a lot. Since Ruby 3.2, `Time.new(iso_string)` is supported, and over 8x faster than `Time.xmlschema`. So if we use the regexp with `match?` to...byroot (Jean Boussier)
> we could estimate the gain by benchmarking with a patch that ignores them Yes that's exactly what I did: https://github.com/Shopify/ruby/commit/bb0cee8daba4b70cedb40b36af05d796956475d6, but that doesn't undo all the constants in `ra...byroot (Jean Boussier)
> those benchmarks already avoid writing, in their hot loops, the kind of slow code that this optimization speeds up That's a very common problem, it's the same issue with `--enable-frozen-string-literal` which doesn't show much gain ...byroot (Jean Boussier)