The point wasn't clear to me immediately. Then I got it and it reminded me of a point ysth mentioned recently: Using an integer as a string usually makes for a considerably larger (in memory) scalar than using a string as a number. So your fix will cause a much bigger problem if you actually used your numbers as both numbers and strings (except it doesn't appear to for integers). Just FYI.

A string, "123" "1.2", likely gets stored in 4 bytes (plus the SV overhead) and then caching the numeric value adds another 8 16 bytes (or so). A number, 123 1.2, gets stored in 8 bytes (or so) and then caching the string value causes a string buffer to be allocated that is large enough to hold any stringified number and that (rather larger) buffer remains attached to the scalar (holding the stringified version of the numeric value).

Note that these considerations usually don't matter. I'm even a little curious how much heap fragmentation played a role in your situation (since each SV has to be reallocated when the numeric value is cached, I assume).

I have never had to resort to such tricks and, when I've needed to reduce memory footprint I've resorted to techniques that (I believe) actually have a more significant impact. Your tactic strikes me as something that is usually a waste to worry about before actually determining that it matters in the paritcular situation. A form of premature micro-optimization.

But I'm also glad to learn of these things, just in case I do run into cases where they point to the easiest way to get enough reduction in memory usage for some practical gain.