On 08/18/12 11:56, Ian MacArthur wrote:
>> 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.
Pretty sure that's due to separate read/write caches.
Caching for reads/writes are usually handled separately.
The 'make' does a write only, running the binary does the read.
But I suppose if you had in your makefile something that read
the binary after it was generated, that'd take care of getting
it in the read cache.
> 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.
I don't think it's so much how long to wait, as how much activity
expires the cache.
I would think loading a really large file would cause the old cache
to dump in favor of the new larger activity. Or running a binary
that uses a lot of free ram would dump the cache.
Depends on free mem; if there's a lot of free mem (which is used as disk
cache on linux IIRC), the caches of old data might stay for a long
while.
> And probably need to break out strace or etc. (as I assume Matthias did!) and
> see where the time is really going anyway.
Write/read caching is done at the kernel level, so I don't think you'll
see
any of that with strace(1) which just traces the user mode system call
interface.
Perhaps dtrace(1) has hooks in the kernel for this.. not sure.
Tracing the disk cache might be tricky.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
