in reply to Efficiency and overhead of subs
Every integer you store (ok...not every one) will be represented internally as a complex 'scalar' structure which knows all about becoming a string, an object and a reference to other types of data.
Not that perl code can't be fast and efficient, but memory footprint is pretty much always going to suck compared to any non-script language.
Does this matter? Depends what you are doing
Its always good to have fast, efficient code. But its better to have readable, correct code which (in the few places it matters) does clever, less obvious things.
Less negatively, you can pack data compactly in perl using functions like pack and unpack. Function calls do have some overhead as in any language, but you could only notice that in a tight loop. There are various introspection options open to you if your perl was built with -DDEBUGGING and there are useful modules on CPAN in the Devel:: hierarchy for profiling.
But my 2p is that general coding style should be optimised for readability, with the hairy bits confined to areas which measurements have shown to be performance critical (and then only if performance is an issue or you have time on your hands).
|
|---|