And you missed mine.
You said it might take a small amount of time to load. Nothing is loaded.
You said the file is read from disk. The file is not accessed.
You said there is something to measure. There is nothing to measure as the module should already have been loaded when mod_perl was loaded, not when a request comes in.
If any of what you said was true, then the difference would be measurable, and it could be sizeable.
| [reply] |
The file is not read from disk for each request, but it is read from disk on startup, even if "startup" only happens once a month. The OP said he was wondering if it could have "any performance impact" (emphasis mine). Startup performance is a subset of performance.
More significantly, time to read the file from disk was simply the first thing that came to mind as something which could be affected by module size. At no time have I said (or intended to imply) that it was the only thing which could be affected. It was meant as an example of a difference, not an exhaustive list of all possible differences.
Even if my example is wrong (which it may or may not be, depending on how broadly you consider "performance"), my point is unaffected: If micro-optimization actually matters for your application, then you're probably better off porting to C rather than worrying about how to squeeze an extra microsecond out of your Perl code.
| [reply] |
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.
| [reply] |