On Sun, Jun 25, 2006 at 07:18:30PM +1000, Scott Smedley wrote: > Hi Dominik, > > Are you enjoying the World Cup? > > > Two reasons: (1) "Schedule" is an unreliable hack and (2) this > > starts a shell every 15 seconds and my goal was to waste as little > > cpu as possible (as it interferes with certain time-critical > > applications - okay - games). > > Hehe. :) > > Re: (2) > > >From some rudimentry tests I've performed on my Linux laptop, using > 'sh' adds little overhead. Your CPU usage is going to be swamped by 'ps'. > > 'ps' performs ~1000 system calls [1], whereas 'sh' performs 116 system > calls [2] - an 11% overhead. Plus you've got a 'sort' in there which is > nearly another 100 system calls. 'sh' isn't going to take any longer > as the number of processes increases, but 'ps' & 'sort' will. > > I realise the number of system calls isn't a direct measurement of > CPU usage, but it's a pretty good metric for the issues you're > considering here.
Your observations are right, and i have replaced the sort call with shell code in the meantime. The button with the top process is just something that I thought would be nice to have, but I never look at it anyway. It's actually not the CPU load that I fear, but the additional disk access and the process spawning costs. The latter is probably irrelevant when it's "ps" you start. > In short, I'm not sure adding a new builtin command to Fvwm to speedup > an arcane situation (by _at best_ 10%) is really worth it, IMHO. That's just one purpose of the command. I was always fond of the idea to prototype or even implement modules as shell scripts. It is no more than a little convenience for the would-be author of a shell script module. It is certainly possible to handle input from fvwm to the module in the script itself, but hard to guarantee that the input is processed in a timely fashion (fvwm may block if not). > I am prepared to write FvwmButtonsUpdater for you (using perllib) if you > need the extra 10% performance, but I can't promise how much faster it > will be. If you do it, don't do it for me but because it's handy. > Having just looked into how Schedule & execute_complex_function() work, > I'm not prepared to blame Schedule just yet. > > In my opinion, I don't think FVWM should grab the X server everytime it > executes a complex function. I realise it's necessary when the function > references the Motion/Click/Hold/Double modifiers but in the majority > of cases, most user functions will just use Immediate. [3] > > This makes me think it would have been nice to separate AddToFunc > into 2 separate commands - AddToMouseFunc & AddToFunc. Where > AddToMouseFunc would permit modifiers, & AddToFunc would _always_ > assume an Immediate modifier. > > As a hack/compromise, maybe we could modify AddToFunc to keep track > of whether or not it uses a "mouse modifier" & only then grab the > X server, in execute_complex_function(). We discussed this a couple of years ago, and Olivier(?) suggested to allow functions without grabbing. The problem is that it is generally unpredictable which functions need to grab and which do not, and you can't do it on the fly because its too late then. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
