Re: Strategies for tracking a tricky (typing) slowdown/lag bug
Re: Strategies for tracking a tricky (typing) slowdown/lag bug
- Subject: Re: Strategies for tracking a tricky (typing) slowdown/lag bug
- From: Keith Blount <email@hidden>
- Date: Wed, 23 Sep 2009 12:06:20 -0700 (PDT)
Jens - Great! Thank you. I had rather stupidly ruled out that method simply because I had tried commenting it out last week and it had had no effect. But of course, I had already spent all of last week optimising the typing and custom text view drawing code, so although it had no noticeable effect when I tried it then, now that the other code is better optimised, commenting out that very method immediately reduced CPU usage to something more like TextEdit's, with around 22% for typing in a new paragraph raising to 30-40%, only going higher on very long paragraphs. After hammering away a couple of thousand words a few times (I now have RSI from all the home-keys nonsense words I have typed today), CPU usage remained constant and there was only the tiniest of lags at the end of very long paragraphs - here's the new sample with the app run with the internals of that method commented out:
http://www.literatureandlatte.com/misc/fssamplebetter.txt
There's still some more to be done, but now I know where to begin - thank you again.
Oh, and yes, the app is indeed Scrivener - thanks for the kind words!
Rick - Many thanks for your comments too. As you can see, you were also on the right track, only it was temporary attributes in my own code rather than Undo that was eating everything up.
All the best,
Keith
--- On Wed, 9/23/09, Jens Alfke <email@hidden> wrote:
> From: Jens Alfke <email@hidden>
> Subject: Re: Strategies for tracking a tricky (typing) slowdown/lag bug
> To: "Keith Blount" <email@hidden>
> Cc: email@hidden
> Date: Wednesday, September 23, 2009, 3:46 PM
>
> On Sep 23, 2009, at 6:55 AM, Keith Blount wrote:
>
> > So now that I know it's CPU, the question is, how do I
> track it, given that I've been having poor luck with
> Activity Monitor and Shark in finding the problem areas of
> code? What I don't understand is how more and more CPU can
> get eaten up like this, when the program is doing the same
> thing. If typing starts eaten up only 22-34% of the CPU, why
> doesn't it stay like this? Obviously it has nothing to do
> with the length of the document, as if the program is
> restarted, CPU usage is back down again when typing in the
> same document (until you add another 1,000 words of
> course).
>
> What it looks like from the sample is that there's some
> pathological explosion of large numbers of temporary
> attributes.
> Nearly all the time is spent inside your -[KMBTextView
> applyTemporaryAttributesToRange:], which in turn spends all
> of its time in -[NSLayoutManager
> removeTemporaryAttribute:forCharacterRange:].
>
> One thing sampling won't tell you is whether a hot method
> is being called many times, or whether it takes a lot of
> time to run. You can answer that by instrumenting your code,
> either keeping a counter or just logging on every call. My
> guess is that these particular methods aren't called that
> many times but are taking a long time. And what that
> NSLayoutManager method is doing is twiddling arrays of
> dictionaries, presumably the style runs and attributes.
>
> Another useful tool at this point would be 'heap', which
> tells you how many blocks are in your process's malloc heap,
> and how many of those are which class of object. You might
> find very large numbers of small objects, if you compare a
> heap dump before and after the app gets into this state.
>
> —Jens
>
> PS: Do you work on Scrivener? I love that app :)
_______________________________________________
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