On 08/18/12 13:28, Ian MacArthur wrote:
>
> On 18 Aug 2012, at 20:25, Greg Ercolano wrote:
>>>
>>> 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.
>
> Yes, I think you are right.
>
> Overall though, maybe that does not matter - probably strace can show us
> where the delays are, I guess, that might be enough?
Oh, you mean delays in the commands FLTK is running,
and not the speed caused by the binary loading..
Yes, 'strace -tt cmd [args]' might be good at showing what's taking so
long.
I often like to use gprof; just compile+link with -pg, and then 'gprof
./cmd [args..]'
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
