Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: How Many Modules Is Too Many?

by dws (Chancellor)
on May 31, 2004 at 15:34 UTC ( [id://357808]=note: print w/replies, xml ) Need Help??


in reply to How Many Modules Is Too Many?

One very practical consideration for using as few modules as necessary (while still using as many as you absolutely need to) is bloat. Bloat bites you in two ways. One is size: pull in enough modules, and pretty soon things like the profiler go haywire. The second is startup speed, which doesn't sound like a bit problem when you're doing a mod_perl app, unless you're heavy into unit tests, in which case the startup hit for pulling in several tens or hundreds of modules bites you every time you execute a .t file. And when you have several hundred tests (a good thing), the additional startup can add minutes to a full test run (a bad thing).

Code reuse is not an absolute good that happens in some ideal vacuum. Reuse is a tool, and like any other tool, it has both benefits and costs.

Replies are listed 'Best First'.
Re^2: How Many Modules Is Too Many?
by adrianh (Chancellor) on May 31, 2004 at 16:07 UTC
    The second is startup speed, which doesn't sound like a bit problem when you're doing a mod_perl app, unless you're heavy into unit tests, in which case the startup hit for pulling in several tens or hundreds of modules bites you every time you execute a .t file. And when you have several hundred tests (a good thing), the additional startup can add minutes to a full test run (a bad thing).

    This problem can (as I'm sure you know :-) be mitigated by building and tearing down your own test fixtures in a single test script rather that using lots of different *.t scripts to isolate your tests.

    I'd probably look towards optimising the test suite before I add the extra overhead of rewriting / inlining modules.

      This problem can (as I'm sure you know :-) be mitigated by building and tearing down your own test fixtures in a single test script rather that using lots of different *.t scripts to isolate your tests.

      Many of our .t files already have over a hundred individual tests (i.e., ok() tests). Each .t does specific setup and teardown, and many use END {} blocks to do useful things like destroy temporary database objects that were inserted for purposes of testing, and which shouldn't be there by the time the next bunch of tests runs. Combining these tests would be possible, but only at the expense of a lot of work. We're getting more mileage by attacking bloat first.

        Each .t does specific setup and teardown, and many use END {} blocks to do useful things like destroy temporary database objects that were inserted for purposes of testing, and which shouldn't be there by the time the next bunch of tests runs.

        Doing this sort of thing for large test suites ended up with me writing Test::Class. It may or may not prove useful to you :-)

        Combining these tests would be possible, but only at the expense of a lot of work. We're getting more mileage by attacking bloat first.

        Whatever works. Refactoring a large test suite can certainly be a huge job (having had to do it a few times in the past).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://357808]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-03-19 03:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found