Re: Profiling a drag and drop operation
Re: Profiling a drag and drop operation
- Subject: Re: Profiling a drag and drop operation
- From: Wade Tregaskis <email@hidden>
- Date: Sat, 06 Jun 2009 00:03:40 -0700
I don't know how well I understand the output I got from it. I
found an area of my code , shark said was taking up about 4.8%,
which was about the third highest entry in the results. Despite
making that change the application, doesn't seem to load the file
any faster. Additional Shark profiling show that changed code is
now longer showing up in the profiling results.
The top entries are all in the operating system or kernel. The top
two are shandler 10.3% and copypv 6.1%, which are both kernel
functions.
The third entry is lseek with 4.1% in libSystemB.dylib. When I
expand this entry it shows the code that I recently changed, which
is trying to check to see if the read position has reached the end
of the file. I'm caching the end position of the file and comparing
the current file position against it. I suspect the lseek command
is what determines the current file position. I'm not sure how I
could improve the check or why it would be slow.
It may be that you're simply blocked much of the time waiting on e.g.
the hard disk. You can use Time Profile (All Thread States) to see
all your time, whether running or not. Or you could take a System
Trace to get an intuitive view (the Timeline) of what's going on with
regards to blocking. The Shark manual is a good thing to read through
(the relevant chapters, at least); it'll explain what you're seeing
and has a kind of Q&A addendum to each chapter, for common patterns
you'll see.
Typically the most common problem with understanding Shark output is
that it defaults to Heavy mode, even though Tree is a lot more
understandable and useful.
The two modes are good for different things. Heavy view is more
intuitive for newbies, and gives you conclusive answers much faster in
those cases where it is applicable. In ATS (All Thread States) mode
particularly so.
Note that your delayed sample trick is unnecessary and potentially
harmful if the sampling goes on for a significant time after your
freeze has stopped. You can start and stop Shark by simply pressing
option-escape, so you can press that as you start your drag, then
again as soon as it unfreezes to ensure that you're only sampling the
right area.
Though the point is well made, I would like to add that in a situation
like this I'd expect you'd be able to use the data mining commands to
quite effectively filter out unrelated code. Though presumably the
app is largely idle before the drag starts and once it is fully
processed, so a standard Time Profile won't have any extraneous data
anyway.
Spin Control is another useful tool here, as it can automatically
start and stop sampling in response to an application no longer
responding to events. Its output is not as comprehensive as Shark's,
but you probably don't need the extra information at this point.
Shark has an analogous feature - choose 'Unresponsive Applications'
from the Sampling menu. It's implicitly recording while active, so
don't be dissuaded by the Start button being disabled.
Wade
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden