Re^4: Measurement of physical memory

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.

Comment on Re^4: Measurement of physical memory

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Optimize algorithms before byte level details
by dragonchild (Archbishop) on Jul 17, 2002 at 22:40 UTC

CGI

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]