On 18 Apr 2002 13:46:21 -0600, Gregg Dameron wrote:
>
> My motivation is to minimize disk reads after the configuration is
> loaded. True, reading and executing a short script from disk is a small
> price to pay; on an idle system you'd never know the difference. But
> the system here on which fvwm runs tends to be anything but idle. When
> interactive performance gets sluggish, our users get cranky.
>
> Bottom line - PipeRead is brilliant, indispensable - I'd like to see it
> be more so.
Well, if you want to get the maximal performance you should do some
benchmarks that are machine dependent.
My guess is that calling many shell utilities (read: many processes) is
sometimes more expensive than one perl script doing the work.
Moreover in pre-2.5.1 you may embed perl in fvwmrc without any additional
processes to be called at all. You should only start FvwmPerl once and do
'SendToModule FvwmPerl eval perl-code' as many times as you want.
The line size limit is not important since you may store the state between
different calls to FvwmPerl. So you may have in .fvwm2rc the following:
# All these commands may be called either in StartFunction or outside
Module FvwmPerl
# find all background pixmaps for a later use
SendToModule FvwmPerl eval $a = $ENV{HOME} . "/bg"; opendir DIR, $a; @b =
grep { /xpm$/ } readdir(DIR); closedir DIR
...
# build a menu of background pixmaps
AddToMenu MyBackgrounds "My Backgrounds" Title
SendToModule FvwmPerl eval foreach $b (@b) { command("AddToMenu MyBackgrounds
'$b' Exec exec xpmroot $a/$b") }
...
# choose a random background to load on start-up
SendToModule FvwmPerl eval command("AddToFunc InitFunction + I Exec exec
xpmroot $a/" . $b[int(random(@b))])
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
