On 10/30/05, Daniel Jalkut <email@hidden> wrote:
> Ya'll need to put up or Shark up :)
Thank you for running Shark!!
> I ran Sanbourne's code on my home directory. Took a long time ... maybe 20
> seconds. In the end, Shark puts most of the blame on FSOpenIterator and
> FSGetCatalogInfoBulk. Together, they take up about 70% of the samples Shark
> was able to gather.
How did you get Shark to tell you this? I have very little experience
with Shark, and when I ran it it said that about 40% of the time was
spent in dyld_something_or_other. How do you get it to show you the
useful information you got?
> The CF stuff looks like noise in comparison, but if I select every CF call
> in the function, it does add up to about 10% of the total function time.
> That's probably worth refining a bit. Too bad it's still going to take an
> eternity in user-time to get the size of my home directory. So you'll have
> to run this on a thread :)
How does it compare to Finder on your computer (which, granted, may be
able to benefit from some creative caching)? Try doing File > Get Info
on your home directory and stop your timer when the directory size
appears. Interestingly enough, I actually found that my routine ran
twice as fast as du -skh, but I guess that's probably an artifact of
caching.
So: You'd recommend trying the STL? Or should I focus on eliminating
recursion and reducing the number of memory allocations by doing this
computation iteratively?
And if you don't mind: How do I use Shark to figure out how much time
is spent allocating memory (and thus answer the above question
myself)? I had trouble making sense of the documentation; it's very
vague/general.
Larry
> On Oct 30, 2005, at 3:43 AM, Laurence Harris wrote:
>
>
>
>
>
> True, but what evidence do you have that CF is faster? In any case, don't
>
> get fixated on STL. If you don't like or want to use STL, that's fine. It
>
> would be simple enough to write code for an efficient stack that would do
>
> the same thing. You're just storing a bunch of 80-byte structs. Nothing is
>
> going to be more efficient than copying them to or reading from slots in an
>
> array.
>
>
--
Larry Sanbourne
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
