Re: Re^2: Measurement of physical memory

If you are using Perl, it's because the development time is faster than anything else out there. You are not using it for it's amazing speed improvements or it's parsimonious memory usage.

Hence, I am of the opinion that, barring gross improvements, optimizations on the scalar level are more than useless. They are counter-productive because you're still thinking in the C/C++ mentality of byte optimization. You've failed to appreciate the Perl mentality of development time optimization.

Some gross improvements could include:

Using parallel arrays instead of hashes when dealing with a very large number of objects, each have 2-3 attributes.
Serializing strings instead of n-deep HoH's (where it makes sense).

Things on that nature. Trying to optimize on the scalar level, especially the scalar string level, is, to me, trying to outfox the Perl interpreter. If you can do that, start guts-jumping and make it better for everyone.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: Re^2: Measurement of physical memory

Replies are listed 'Best First'.
Re^4: Measurement of physical memory by tadman (Prior) on Jul 17, 2002 at 20:40 UTC
Although I could be wrong, I think the idea was to determine the length of a string in bytes, which has many, many practical applications outside of optimization. What if you're trying to generate the equivalent of a "Content-Size:" header? Your response suggested that if you need to do such a thing, you shouldn't be using Perl!. That's not very constructive advice. Is there anything wrong with optimizing your Perl programs? Is Perl some kind of toy language that isn't supposed to be optimized? You've got to be joking. I think a little insight into how big things are is important, and at times, I'm a little disappointed that I can't find out. If I'm loading half-a-bajillion records, I'd like to know that one structure takes up half the RAM of another. I'd like to know which routine runs four times faster, or uses less disk I/O. Is this crazy? Once the decision to use Perl has been made, you shouldn't have to give up common sense.	[reply]
Optimize algorithms before byte level details by dragonchild (Archbishop) on Jul 17, 2002 at 22:40 UTC
To create a "Content-Size:" header, yes, I can see the benefits of determining the length of a string. Or, might it not be better for CGI to tell you how big your page is? As for optimizing Perl ... Yes, Perl should be optimized. In fact, a large part of my jobs tend to be cleaning up de-optimized Perl code. However, I assume that the interpreter will optimize things like the size of the scalar for me. I don't worry about implementation details - I worry about optimizing my algorithms first! As for wondering how big the fine details are ... yeah, it's cool to know. Then, it's important to forget. I think it's more important to know that a hash takes more memory than an array or a closure. So, if you want to optimize, optimize using standard knowledge. Don't start optimizing on the byte level. That is what my intention was to say. If you're at the point where every other thing is optimized, optimize your choice of language to something that allows you to easily deal with that ... like ASM. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]