in reply to Re: Re: Re: to strict or not to strict
in thread to strict or not to strict

Well, yes, that's what I meant when I said "I assume you're referring to the runtime check for symbolic references, as that is the only run-time component for stricture?" ;-) Personally, I always forget about module loading times, because I do most of my Perl work with mod_perl, with all modules loaded at server startup time.

But I am pleasantly surprised by the low overhead of loading strict: being able to load strict more than 1 million times per second is nice. But on the other hand, it indicates to me that the OS has the file in RAM already and is serving it from there. So in that sense the benchmark is also flawed ;-).

Anyway, I think we've proven there is not a lot to be gained by not using strict from a performance point of view. And that there is a lot to be lost from a development / maintenance point of view (if you don't use strict).

Liz

  • Comment on Re: Re: Re: Re: to strict or not to strict

Replies are listed 'Best First'.
Re: to strict or not to strict
by Abigail-II (Bishop) on Oct 17, 2003 at 09:36 UTC
    But on the other hand, it indicates to me that the OS has the file in RAM already and is serving it from there. So in that sense the benchmark is also flawed ;-).

    Yes, and no. If you have a situation where the OS hasn't cached 'strict.pm', it means 'strict.pm' isn't used relatively often. But the less something is used, the less it's a bottleneck, and the less impact higher load times have.

    So, you are right, but in situations where you are right, the outcome of the Benchmark isn't that important.

    Abigail