|No such thing as a small change|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
Anyhow, does your comment mean that Devel::Size is not reporting the size related to the entire PV buffer allocated
Wow, you are actually considering believing some second-hand hear-say over numbers output by a module in black-and-white? (:
I just restated what ysth said. It made sense to me and I trust ysth but I didn't do any experiments to validate the claims. Perhaps ysth will provide some details. It certainly could be a "problem" only on a different version of Perl than what you tested on, for example. Or it may have been a misinterpretation of some data on ysth's part; after all, it was a rather casual comment and so I may have erred to elevate it to the level of a node or just misinterpretted it. We'll see what others contribute.
Thanks for testing it.
Looking at some source code, using an NV instead of an IV likely makes the difference (which testing shows is true on my version of Perl, allocating 36 bytes for the string "1.1", roughly doubling the size of ($x=1.1).='' over ($y='1.1')+=0; not a huge difference in most situations). The code appears to pre-construct the string then allocate/copy just the required size for an IV or UV but to allocate the buffer in the SV first when converting an NV. And based on ysth's comment, I wouldn't be surprised if the NV case has changed in some development version of Perl.
In reply to Re^3: Strings and numbers: losing memory and mind. (SV sizes)