Yes I thumbed it down. 7.8 is supposed to be stable, afterall. That means bug fixes is supposed to happen there, nothing else. And optimizations aren't bug fixes. Albeit this rule is broken frequently (by myself as well), it still ought to be kept in mind. Non-bugfixes can be fine if they don't affect any existing functionality (that's why I e.g. thought it was ok to add Standards.JSON), but optimizations aren't like that.
Sure it's annoying that 7.9 never opens up, but bending this rule isn't the answer to that problem. And it is afterall possible to commit stuff without doing it in 7.8: The pikex git repo works, for instance; my hacks are on the mast/sneak-7.9 branch. When it comes to breaking the bugfixes-only rule, it should be done with care at least. Small well-localized optimizations that are fairly simple to verify, like the copy_value() optimization, are easier to swallow. Tweaking hash algorithms isn't like that - it might give O(n) in some situation out there. It's unlikely, but even a slim risk is imo not acceptable in a supposedly stable version. We know what we have, but if we don't know what we'll get then it should not happen in 7.8. > /.../ remove an odd restriction that identifier caching only happens > in objects with >= 9 identifiers. /.../ I guess the reasoning behind that is that the hash table doesn't give any appreciable speedup when the identifiers are very few, and so it's better to not pollute it with those. Whether it's correct or not I don't know. The proper thing to do would be to test both with a lower limit and without it. Anyway, that's a tweak I'd find easier to accept.
