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: Tue, 22 Sep 2009 15:51:39 -0700 (PDT)
Many thanks for the reply, Jens, much appreciated. Using sample via the Terminal proved very useful. Interestingly, while I was messing with the settings trying to get it to work, I found something while my app was supposedly idle before I even set it up ready to hammer away at the keys - there was a QuickTime callback (the app can handle various types of file) that was being called repeatedly in the background even when no QuickTime file was being used or viewed. I'd missed this before because I had been so busy sampling and testing the app while hammering the keys that I had failed to do so while idle, so the responsible calls got buried in other stuff.
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. Now that the QuickTime bug is out of the way, sampling while typing in full screen is mostly only giving me internal text view methods, and the ones of my own I've already tried commenting out and re-testing to no discernible effect. Sampling only gives me an idea of where the time is being spent, not (at least on the commandline) what is eating up memory (and as I say, I've had no luck with Leaks). And when I try to hammer the keys while running some Instruments - such as Activity Monitor and Zombies at the same time - my MacBook becomes so unresponsive because of the data the Instruments are trying to process that I end up having to reboot.
For the record, I'm not using any deprecated APIs in the text system. My app is linked against 10.4 and above, but with runtime checks to use newer methods where possible. So, if run on Leopard or above, for instance, it uses non-contiguous layout etc. (The text system is normally fast, as you say, but has its limitations - for instance, it can slow to a crawl when editing at the top of a long text using justified alignment.)
Many thanks again for the pointers. If anyone has any further suggestions for next steps in trying to locate the cause of such a tricky slowdown issue (as I say, the slow down only appears after typing a couple of thousand words, with the app having been running a couple of hours, and is fine when it's relaunched again) for which I'm not having much luck so far with Instruments, I'd be very grateful.
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, 12:42 AM
>
> On Sep 21, 2009, at 3:40 PM, Keith Blount wrote:
>
> > My app uses a heavily modified version of the OS X
> text system and has some typing lag issues. Generally it has
> always been fine, but in some circumstances typing would
> slow down (sometimes this is in part attributable to
> the fault of the OS X text system itself, which can slow to
> a crawl when trying to deal with even a few thousand words
> of justified text, but mostly it seems to be the result of a
> combination of factors in the highly customised and
> subclassed version of the text system my app uses).
>
> The text system is normally really fast. IIRC, it might
> have some backward-compatibility hacks that will cause it to
> work less efficiently if it finds that it's been customized
> in some deprecated ways (instead of just failing.) Are you
> sure the techniques you're using are the currently
> recommended ones and you're not using any deprecated APIs?
>
> > Given that it gets slower over time and with typing,
> but clears out as soon as it’s quit and re-launched, I
> figured this must be a memory problem, but Leaks doesn’t
> seem to give me any useful information
>
> The first thing I would use is sampling. Use the 'sample'
> tool, the sample command in ActivityMonitor, or Shark's CPU
> sampling mode to see where the time is going. For things
> that require user interaction, what I usually do is enter
> "sleep 5; sample MyApp 5" at a shell, then immediately click
> into my app and start banging away at it so it's busy when
> the sampling begins.
>
> —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