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 06:55:38 -0700 (PDT)
Hi,
Again, many thanks for the help, I really appreciate it.
To answer Rick's question first - the lag only occurs after typing for a while, yes (about 1,000 - 2,000 words). It doesn't happen if you just paste text in, or in documents that have only just been opened but already contain thousands of words of text.
Jens - you clearly know what you're talking about as you are, of course, absolutely right. I followed your instructions and used top in Terminal, and my app's memory doesn’t swell to anything horrific at all. 'RPRVT' starts at around 19-20MB and by the time typing is slowing to a crawl it is not much larger, at around 21-22MB.
'%CPU', on the other hand, went through the roof. I compared it to TextEdit (creating the same sized text area in both), and this is what I found:
In TextEdit, typing in text documents containing lots of justified text caused %CPU to hit about 51-74%, which was similar to my own app to begin with. But then I got rid of all of the justified text and stuck to left-aligned ragged text, and immediately saw my app eat up CPU whereas TextEdit remained constant.
In the same text, typing in the same area, TextEdit used between 12.4-30% of the CPU. It averaged out at around 17%, rising to around 30% as a paragraph got longer and longer.
My app, started with CPU usage around 22-34%. Obviously this is a largish increase over TextEdit, but not bad considering the extra things my app does (live word count, extra formatting, different objects monitoring the text etc), and certainly still more than nippy. However, the more you type, the more it eats into the CPU. CPU usage soon grows to around 40-50% as a paragraph grows, and then new paragraphs start eating up 30-40%. After typing a couple more paragraphs, CPU grows to between 40-50% when typing at the beginning of a new paragraph, rising to 60% as the paragraph grows in length. Once you get to about 1,500 words, CPU usage reaches 100% (100.1% even...) for long paragraphs, and is hitting 98.8% typing the beginning of a new paragraph. Needless to say, by this time, typing is severely lagging.
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).
Here's the report from sample, taken while typing at its slowest:
http://www.literatureandlatte.com/misc/fssample.txt
I'm failing to see the problem areas - the -didChangeText, -applyTemporaryAttributesToRange (and other temporary attributes methods) stuff I've all tried commenting out, with no discernible difference.
Apologies for the long mail.
Many thanks again and all the best,
Keith
--- On Tue, 9/22/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: Tuesday, September 22, 2009, 11:18 PM
>
> On Sep 22, 2009, at 3:51 PM, Keith Blount wrote:
>
> > Initial tests suggest this has improved things a
> little, but I'm not confident it's the only cause. The way
> that typing would get slower and slower over time, and then
> speed up again once the app was quit and relaunched, means
> that I'm still worried there's a nasty memory bug lurking
> somewhere.
>
> Slowdown doesn't necessarily mean memory leak. Use top or
> Activity Monitor to look at the 'RPRVT' of your app —
> that's the amount of non-shared memory it's allocated that's
> in RAM. Unless you see that ballooning to hundreds of
> megabytes, I don't think memory is the problem.
>
> —Jens
_______________________________________________
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