You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Will Fould <wi...@gmail.com> on 2006/11/12 08:01:30 UTC
breaking packages into smaller files for performance?
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 subs
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.
Was:
package foo
[a,b,c] (~350k)
Now:
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.
W
Re: breaking packages into smaller files for performance?
Posted by ri...@logicmerc.com.
> 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
> subs
> 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.
>
> Was:
>
> package foo
>
> [a,b,c] (~350k)
>
> Now:
>
> 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.
>
> W
>
Will,
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
the server.
Rick
Re: breaking packages into smaller files for performance?
Posted by Will Fould <wi...@gmail.com>.
> No offense, but I've never seen a 350k module that didn't need
> to be broken into SEVERAL other modules for
> readability/maintainability reasons.
Thats the plan. It's easy to visualize: This single file is an old CGI
script/application maintained over 4 years with lots of shared subs that do
everything from authentication, database access, web screen templates,
logging and error handling. It was ported to a mod_perl environment last
year. But, as a single file, it was easy to edit and work on as a single
developer with a text editor.
I'd only guess that a lot of folks have skeltons like this in their closet.
; )
On 11/12/06, Frank Wiles <fr...@wiles.org> wrote:
>
> On Sat, 11 Nov 2006 23:01:30 -0800
> "Will Fould" <wi...@gmail.com> wrote:
>
> > 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 subs 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.
>
> You won't see any real performance improvement, but it certainly
> would be an improvement to your code.
>
> No offense, but I've never seen a 350k module that didn't need
> to be broken into SEVERAL other modules for
> readability/maintainability reasons.
>
> I'm over generalizing here and not taking into account
> bloated/memory hogging modules, but files/packages/modules
> are cheap to use and create and should be broken up for reasons
> other than performance.
>
> I just looked over one of the largest mod_perl apps I help
> maintain, there are 67 modules and only one of them is over
> 20k in size.
>
> ---------------------------------
> Frank Wiles <fr...@wiles.org>
> http://www.wiles.org
> ---------------------------------
>
>
Re: breaking packages into smaller files for performance?
Posted by Frank Wiles <fr...@wiles.org>.
On Sat, 11 Nov 2006 23:01:30 -0800
"Will Fould" <wi...@gmail.com> wrote:
> 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 subs 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.
You won't see any real performance improvement, but it certainly
would be an improvement to your code.
No offense, but I've never seen a 350k module that didn't need
to be broken into SEVERAL other modules for
readability/maintainability reasons.
I'm over generalizing here and not taking into account
bloated/memory hogging modules, but files/packages/modules
are cheap to use and create and should be broken up for reasons
other than performance.
I just looked over one of the largest mod_perl apps I help
maintain, there are 67 modules and only one of them is over
20k in size.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------