in reply to Re: Re: Module Efficiency
in thread Module Efficiency

Do you care to justify that with a some facts? I'd rather have a correct program that's slow than an incorrect program that's fast.

Coplan didn't say "this subroutine is slowing my program down". The question that Coplan was asking was a general question about efficiency. That's focusing on how fast the tires are turning and ignoring that you're about to crash. If, instead, I focus on whether or not my system is properly organized with minimal duplication of code and written in a clear, easy to read manner, then I can focus on what might be truly affecting my performance. Trying to improve the performance of a nested loop that ultimately only uses a half percent of the runtime is probably a poor utilization of resources. That is the real inefficiency.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

  • Comment on Re(3)Module Efficiency (with a side order of facts, please)

Replies are listed 'Best First'.
Re: Re(3)Module Efficiency (with a side order of facts, please)
by Anonymous Monk on Apr 10, 2003 at 22:34 UTC

    I interpreted the question to ask:

    <paraphrase>Are their any performance penalties from the use of modules?</paraphrase>

    I can think of several ways of answering this question.

    I might discuss the trade-off between the load-time cost of use v the runtime cost of require. Or consider the trade-off between the load-regardless nature of use v the possible saving of conditional loading via require. Or consider the possibility of runtime autoloading etc.

    I might point out that, once loaded, procedural subs within a module will carry exactly the same costs as those loaded via require.

    I might discuss the performance penalty of tie and calling object methods and contrast that with the benefits of reusablility.

    I would point out that code in modules is just as likely to be incorrect as code that isn't in a module. Modularisation has little or nothing to do with correctness. Fast code can be correct and modules can contain errors.

    Having an interest in, and being aware of, both the benefits and the costs of the various Ways To Do It, does not automatically translate into 'give me speed at the cost of correctness'. If fact, awarness of the costs up front can lead to design decisions that can benefit the code in terms of both performance and correctness. Conversely, ignorance of them can lead to algorithms and implementations that become impossible to optimise to achieved the desired or required performance without resorting to the use of tricks and dodges in order to avoid total re-writes.

    I would agree with you that there is no point in doing something wrong, very quickly, but there is equally no point in getting the right answer 2 days after it is needed.

    Performance is just one of many factors that must be considered when setting out to design code. It should not take higher precedence in the process than anything else that is more important. Dumb statement, but the relative importance of the many design criteria is dependant upon the needs of each individual project. Some projects do need a certain level of performance, and being aware of the factors that can affect performance at the outset is no bad thing as it allows better decisions to be made in a timely fashion. A stitch in time and all that.

      Okay, that to me is a much better response. You raise some valid points rather than dismissing my reply out of hand. Reading something like this is meaningful to me. Thank you :)

      The person made it clear that they weren't terribly familiar with modules, so I don't know that I would bring up issues such as tie and autoloading, but that's not a reason not to bring them up. If someone asks a beginner question, I guess that I'm more inclined to give a basic answer.

      The only nit that I'd pick with what you wrote is when you claim that "modularisation has little or nothing to do with correctness." Strictly speaking, this is correct. If I am building a large system and I repeat the same, perfectly correct snippet in 30 different places in the code, everything runs fine. However, when my business rules change and I need to change those 30 instances, then I would argue that while the code may have been correct, the design was not. Further, with a well designed and modularized system, the benchmarking is easier and when different sections of the code are properly decoupled, fine-tuning a particular section is much easier. Heck, if done right, you could even use XS for the nasty bits, but I probably wouldn't bring that up, either ...

      The code and the design of the code go hand in hand. Even if the code is correct, the design might not be and I think that's important to stress. Other than that, I think you raised some good points.

      Cheers,
      Ovid

      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

        If ... I repeat the same, perfectly correct snippet in 30 different places in the code...

        That is equally well addressed by using require snippet.pl; as use Snippet.pm, but then I realise that both are covered by the term "modularization" in the generic sense as opposed to the Perl Module (.pm) sense of the term I was thinking of when I used it. I also realise that it wasn't clear from the original post that the writer was using require either.