Talk about premature condemnation of optimisation.

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)

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.