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.
