On Fri 22 Aug 2008 at 07:22:52 -0500, Matthew D. Fuller wrote: > 1) Rearrange the right side so there's no multiplying by 100 needed. > Instead, we eat a floating point operation, which will be slower, > but give a correct answer. I can't figure how the speed matters in > the slightest.
The speed can be much worse than you think. If this new floating point operation is the only, or one of the very few floating point operations in the program (in other words, if this is the first and only FP operation in the current timeslice that ctwm gets), and the operating system uses lazy FPU state switching, then it will cause a trap to the kernel to set up the FPU. This is much slower than just executing a FP operation. It potentially involves inter-CPU communication (for SMP machines) if the FPU state is on some other CPU. If ctwm does many other FP operations this does not matter, the cost has already been paid. Checking, I see some already for opaque move in menu.c, and with the seldom-used F_MOVETITLEBAR action. FP also seems to be used for effects with iconifying windows (SweepWindow() and waitamoment()). In util.c it is used for colour shading (in menus I suppose). In workmgr.c it is used more extensively for the workspace manager window. This is probably fairly common (at least with how I use ctwm) since it needs to recalculate the mini window positions if there is any geometry change in a window somewhere. Now how much this means in practice is difficult to predict. One useful rule I apply is that if something relatively slow happens directly as a result of user action, it doesn't matter, since humans are even slower. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.