This is a discussion on Re: breaking packages into smaller files for performance? - modperl ; > I've found conflicting information about this. > > modperl: Is there a performance impact to breaking up a single 350k file > (monolithic package) into multiple files (still the same package name)? > > I guess I'm asking: Are ...
> I've found conflicting information about this.
> modperl: Is there a performance impact to breaking up a single 350k file
> (monolithic package) into multiple files (still the same package name)?
> I guess I'm asking: Are larger files inherently slower, even when
> pre-compiled? (Obviously, I'm not a computer science student)
> Here's the situation:
> Over time, what was a 60k package has grown to 350k, encompassing many
> that do more or less, 3 mutually exclusive operations. I want to remove
> 70% of the subs and put them into their own files for
> maintenace/organization reasons, but is there a performance benefit or hit
> by doing this? The main file will basically direct, requireing the
> additional files only when necessary. But under mod perl, I believe the
> require will only happen once (per process) anyway.
> package foo
> [a,b,c] (~350k)
> package foo
> [a] (~75k)
> require [b] (~115k) only when necessary
> require [c] (~160k) only when necessary
> Thank you for enlightenment or a reference link, in advance.
The only performance you will gain from doing this is that it will take
Apache less amount of time to start each process. Also if your package foo
makes calls to packages containing b & c routines, it will incur the
performance hit of loading those packages the first time 'foo' requires
them. In your example, I think that the benefits would not be as large as
you might hope for.
In fact, sometimes it is better to preload/compile all the classes you
will be using when starting an apache process. This way, none of the users
will have to take that initial hit of compiling. To do this, you can just
use the 'use' statement to preload any classes/modules you plan on using
in your apache startup or config files. You can also take advantage of
running some initialization code during the preload. A great example would
be initializing DBI so it doesn't have to be done on the first request to