Hi Dominik.
> > > I intend to start looking at the processing of the NotifyMotion events > > > because I think > > > we can find some inprovement in handling that event since it is received > > > by apps > > > registered for it much more than any event. I noticed that it is in the > > > main switch for > > > FvwmIconMan. I'm trying to measure right now the gain by having an if > > > trap this event > > > prior to entering the switch(). switch() is slower when 1 case is called > > > significantly > > > more times than any other case. What do you think? > > > > (You should rather create a new mail thread for new topics - I > > almost overlooked this one.) Just making sure you are still awake ;-) > > I've never compared switch and if, so I don't know if it makes any > > noticable difference. But anyway, FvwmIconMan only requests > > Motion Notify events when a button is held down. This only occurs > > if the user presses a button inside FvwmIconMan and then drags the > > mouse. Since FvwmIconMan is the active application at that > > moment, it's not *that* bad. > > I have to take that back. Actually, FvwmIconMan requests all > motion events to be reported, not just when a button is pressed. > I looked in the wrong place. Yep, when I was examining the events flying around for the background redrawing I noticed this flew significantly more than anything else. I will try to put together some quantitive analysis of switch/if. It will of course depend on the compiler and optimiser settings so I will try to factor that in. In general, there is little a compiler can do to detect that one case is executed more than the rest. The only way to minimise the impact without code modification is to use a binary tree search, and it is a minimisation effort. Code modifications can be accomplised by design, filtering them out before the switch, or ordering the case statements in order of importance - both depend on compiler implementation. There is simply no way in the language to define one case as more important as another. I will write something up for this. As with safemalloc, optimisation is probably only worth it in focused areas. Cheers Dave > > Bye > > Dominik ^_^ ^_^ > > -- > Dominik Vogt, [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > -- > 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] -- 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]