Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

Overhead for "get_plugin_user_cfg"??

Quote Reply
Overhead for "get_plugin_user_cfg"??
Alex,

In most of the plugins/mods I've been doing, I've defined a global at the top of the module, and assigned it:

$PLUGIN_CFG = Links::Plugins::get_plugin_user_cfg ($PLUGIN_NAME);

Assigning it once in the script, after the environment check, is more efficient, on the surface, than asking for $cfg in each and every subroutine that is used. That worked ok, before the breakup <G>

I need to generalize it, so I can pass a parameter PLUGIN_NAME to the modules, and have them load the defaults for whatever plugin is calling them at the moment.

The problem is, that this load_defaults routine could be called 12 or more times in the course of even a simple operation if it was called in each subroutine that used default values. The defaults play a heavy role in the process, and there is no "luxury" of a single $CFG value, since there are multiple plugins.

Is it still "better" to define $PLUGIN_CFG as a global, and then assign it once, at the main point of entry into the module, and just make sure that every call to the module is handled by that "dispatch" routine? Or is the "load" call cached, so there is trivial overhead? It still seems cleaner, and less prone to obscure errors, if the defaults were obtained once, then made accessible to everyone. It also seems there'd be less "copies" of this data around, and fewer pointers or references (lower memory, stack and sym tables usage) from perl's point of view as well.

I know worrying about memory usage in perl is not something thought about often, but with potentially a large number of processes running, all making dozens of calls, possibly 2 or 3 subroutines deep, getting rid of redundant calls, assignments and resource usage seems appropriate (at least to consider <G>).

The subtlties of this are what's driving me nuts, not the gross implementation. I don't know enough about perl internals or even the GT internals, to figure out something like this. Two conding paradigms are in conflict, and I don't know how to resolve it.

Heck, we ask perl to slurp whole directories, and I'm worried about a handful of bytes :)

FWIW... for the newbie... these "handfuls of bytes" actually add up more insidiously than the file slurping, since they are inobvious, and a large program can have literally thousands of such redundancies and inefficiencies. Multiply that by each running process or request, compound it by using mod_perl, and suddenly it's not a handful, but more like a swap file full. You at least need to think about them, even if you don't (or can't) do anything about them. Put another way, you pretty much know when you are slurping files, or doing unnecessary SELECT * queries, but you really don't know when you are leaking or stacking resources internally, unless you think about it -- and that only usually happens in the actual coding phase, while it's fresh on your mind (or, in a panic later on, when things go boom!!).



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
Quote Reply
Re: Overhad for "get_plugin_user_cfg"?? In reply to
Hi,

The problem with what you are doing is it breaks under mod_perl. You will not see changes to your plugin unless people restart the mod_perl server.

The call has very little overhead, it is just getting a reference to the master config file (which is loaded every request anyway). I would not worry about calling it in the subroutines you need config information.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Overhead for "get_plugin_user_cfg"?? In reply to
Alex,

Can't you force a reload? You do that with the $USER variable.

Isn't there a way to access if ($PERSIST) {reload $PLUGIN_CFG} within mod_perl?


PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin