Re: source'ing files in multiple places - why bad?

gamename wrote:

> Hi,

> Its long been part of tribal lore that sourcing the same file from
> multiple places in the same script invocation is a bad idea. But why
> is it a bad idea? I have users who are unwilling to even view this as
> an issue. So, I wanted to get everyone's input to help me respond.

> Is there any way to quantify in what way this can cause problems?
> Processor/memory overhead maybe?

Here are the reasons I can think of, just off the top of my head:

1. "Self-modifying" code is hard to debug. Period. Sourcing a file can
certainly have the effect of modifying procs already in memory. If a
failure occurs, you won't know for certain, without a lot of work, where
the "source" of the problem is. Of course, such things can be very
*useful* at times. I have, myself, defined or modified procs on-the-fly
within code. But it can be extremely difficult to work with.

2. Move your application to a new location. Did you get all the files
you need? Are you absolutely sure? If you source them all at the
start, you'll have only one place to look for dependencies. If you
source them all over the place, you'll have to search hard to find them.
Exponentially so if you source filenames contained in variables.

3. Network reliability: Work with the files over the network. Now the
amount of time it takes to run any particular bit of code that may
source a file is dependent on network lag. You want to quantify the
time hit? I have one phrase for you "NFS sever down." Anyone who has
seen a building full of workstations brought to a grinding halt as the
OS waits for the NFS server to reboot will appreciate that NOT having
all of your code in memory when you KNOW it's available means that
execution time could go from 1 minute to 1 hour. Sure, NFS can be tuned
to soft-fail, and SMB, AFP, or other network filesystems can "fail"
early, not bringing down the whole machine, but it still means a failure.

4. Local filesystem reliability: at any given time, what else is
accessing your local filesystem? Why wait for it in the middle of
execution? Has your code, or any other process, modified mount points
while your process is running?

5. Repeatedly accessing the filesystem is slower than storing routines
in a proc. If you want to compare speed of access to disk to speed of
access to core, I suggest you pull all but 128Mb out of the machine
you're sitting at right now, load up Windows/OSX/GNOME/KDE/CDE, then
kick off a browser, a word processor, and a few other apps. See how
quickly things run? That's the extra speed hit you get in the middle of
execution, albeit for accessing perhaps a few kb rather than swapping
out a few hundred megs, but even a few extra hundred milliseconds may be
important, depending on your application.

-- 
MKS