Re: Profiling a drag and drop operation
Re: Profiling a drag and drop operation
- Subject: Re: Profiling a drag and drop operation
- From: Tron Thomas <email@hidden>
- Date: Fri, 05 Jun 2009 15:56:27 -0700
Nick Zitzmann wrote:
On Jun 5, 2009, at 4:11 PM, Tron Thomas wrote:
What could allow me to determine why the new program is much slower
when trying to deal with this dropped file?
Have you tried reproducing the problem with Shark running and sampling
the app? Shark comes with the developer tools, unless you disabled the
CHUD installation.
Nick Zitzmann
<http://www.chronosnet.com/>
Yes, I had tried a time profile using Shark, delaying the sampling until
5 seconds after the application started. This allowed me to drop the
file just after I knew the profiling had begun.
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.
_______________________________________________
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