Re^6: Does module size matter under mod

The OP said he was wondering if it could have "any performance impact"

Do you really think he's interested in the performance of the startup of the web server? I doubt it.

But if so, your answer is still completely wrong. We're easily talking seconds, not something so small it can't be measured. For virtually everyone using them, the entire point of using mod_perl or Fast CGI is to eliminate that delay you claim is unnoticeable.

Refactoring into smaller modules isn't going to help. The same code still needs to be loaded and compiled.

Comment on Re^6: Does module size matter under mod_perl?

Replies are listed 'Best First'.
Re^7: Does module size matter under mod_perl? by dsheroh (Monsignor) on Jul 09, 2014 at 08:10 UTC
I get it. You hate my example. I get it. My example was probably poorly chosen. I get it. But you seem set on refusing to accept that the example was not the point of my answer. Loading one big file (one meaning of "module" in the Perl context) will not take the exact same amount of time, down to the attosecond, as loading several small files which are functionally equivalent. Running code from one big namespace (another meaning of "module" in the Perl context) will not take the exact same amount of time, down to the attosecond, as running code which is spread across multiple namespaces. If you look closely enough, refactoring always has an effect on performance, unless it is such a trivial refactor that the processor still runs the exact same opcodes. But, in practical terms, that generally doesn't matter. And, if you're performance-sensitive enough that it does matter, then you'll get more benefits from using a high-performance language than you will from moving code around between files and/or namespaces. That was the point of my answer: Don't waste your time worrying about micro-optimization. Which remains good advice even if I supported it with a poor example. Finally, if you're going to say I'm "still completely wrong", please at least point out the complete wrongness of things I actually said. I never said that load times are potentially unmeasurable. I said the difference in load time between loading a single file and loading equivalent code from multiple files may not be measurable: "the difference is completely unimportant, if there's even a measurable difference at all" (emphasis added)	[reply]

Replies are listed 'Best First'.

Re^7: Does module size matter under mod_perl?
by dsheroh (Monsignor) on Jul 09, 2014 at 08:10 UTC

I get it.

But you seem set on refusing to accept that the example was not the point of my answer.

Loading one big file (one meaning of "module" in the Perl context) will not take the exact same amount of time, down to the attosecond, as loading several small files which are functionally equivalent.

Running code from one big namespace (another meaning of "module" in the Perl context) will not take the exact same amount of time, down to the attosecond, as running code which is spread across multiple namespaces.

If you look closely enough, refactoring always has an effect on performance, unless it is such a trivial refactor that the processor still runs the exact same opcodes.

But, in practical terms, that generally doesn't matter. And, if you're performance-sensitive enough that it does matter, then you'll get more benefits from using a high-performance language than you will from moving code around between files and/or namespaces.

That was the point of my answer: Don't waste your time worrying about micro-optimization. Which remains good advice even if I supported it with a poor example.

Finally, if you're going to say I'm "still completely wrong", please at least point out the complete wrongness of things I actually said. I never said that load times are potentially unmeasurable. I said the difference in load time between loading a single file and loading equivalent code from multiple files may not be measurable:

"the difference is completely unimportant, if there's even a measurable difference at all" (emphasis added)

[reply]