I hope perl is not so inefficient that it copies all the content of a list when it needs to process it, when simply pointing to the already allocated elements would be enough. Even more so with arrays. I'd also expect some COW mechanism to remove a lot of allocating and copying. Keys might be more trouble though, as all data stored in them have to be stringified first (and I wouldn't be surprised to learn that hash keys always hold a copy of the initial string, since as far as I can tell they are not standard scalar values). I agree that the memory usage, and number of copies is certainly higher when you go all the way to slicing, but I don't expect "at least 4 times more" memory. Actually I remember finding out in a post a while ago that having the keys and values in two arrays takes more place than just having them in a hash (which kind of makes sense, order is extra information, although technically I think it's because keys can afford to just be strings, without all the extras of ordinary scalar values)
Not so much "missed it" as chose not to address it.Well that's too bad, you did have an interresting answer: that if you need to gather your data in some form before populating your hash, you shouldn't expect to obtain the best result memory-wise and time-wise (because of the copies). So you probably don't need to worry about preallocation if you don't need to worry about slicing.
In reply to Re^4: Does "preallocating hash improve performance"? Or "using a hash slice"?
by Eily
in thread Does "preallocating hash improve performance"? Or "using a hash slice"?
by vr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |