On 17 Aug 2012, at 19:35, Greg Ercolano wrote: > On 08/17/12 05:06, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> Just for kicks'n'giggles I ported the code to WinXP using the >> QueryPerformanceCounter() API to get timings, and I get... >> [..] >> ian.macarthur@DESDAF599172 /d/examples/qix-win-times >> $ ./qix >> New control cost 0.02(ms) >> Show window cost 21.23(ms) >> [..] > > Here's what I get on centos 5.6 on a 1.8ghz mac mini: > > 08/17/12 11:28:22 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 127 # ./foo > New control cost 0(ms) > Show window cost 109(ms) <-- FIRST RUN > > 08/17/12 11:28:29 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 128 # ./foo > New control cost 0(ms) > Show window cost 11(ms) <-- > > 08/17/12 11:28:31 /usr/local/src/fltk-1.3.x-svn/examples > [erco@tahoe] 129 # ./foo > New control cost 0(ms) > Show window cost 10(ms) <-- > > That first run of 109ms shows the overhead of pulling the binary off > disk, > and the subsequent runs are shaving off 100ms because they're obviously > running > from the disk cache, such that it's only 10ms.
Huh! That's odd - but makes sense I guess. I have mainly been testing by running " make && ./qix " so that tends to mean the binary blob is already in memory on the first run anyway, so I'm not seeing a hit from loading/caching on first run... Well, I guess that might be why. I should try to run it after the system has had a long time to forget, see if I can see a hit on the first invocation. And probably need to break out strace or etc. (as I assume Matthias did!) and see where the time is really going anyway. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
