Re: XCode editor intolerably slow
Re: XCode editor intolerably slow
- Subject: Re: XCode editor intolerably slow
- From: David Ewing <email@hidden>
- Date: Thu, 28 Jul 2005 14:10:14 -0600
On Jul 28, 2005, at 12:44 PM, Andreas Grosam wrote:
I used spin control and Shark in order to investigate this. I have
several dozends entries of hangs in Spin control, ranging from 2
secs to more than 700 seconds. Which one do you want?
Zip 'em up and send 'em all. If you can describe what was going on in
each, that might help. Then again, it's usually pretty obvious.
This is that obvious, I think you can make your own:
You need to use just a file with 25k lines. Open it in the editor.
When you load a new file in the editor, the function popup takes
some time to be enabled. It is proportional to the file size. It
takes roughly 3 .. 4 seconds per 1000 lines (on my old G4 800 MHz).
After that, when you click in the popup, it takes again a
noticeable delay.
The latter delay will be caused by text/font format functions in
NSLayoutManager and NSATSTypeSetter.
Switch the files from the history popup. Once you switch back to
your big file, a funny progress bar in the middle of the editor
view might appear, labeled "Loading...".
These all sound like issues with text layout being slow for large
files. The only one that I don't remember seeing before is the delay
occurring when clicking on the popup. A sample for that would be
good. As I said, we're working with AppKit folks pretty closely on this.
When you try to scroll, the whole system may stuck. The system UI
might not respond anymore, no spin cursor, no window manager
responding, no chance to kill, everything seams frozen - but after
20minutes, the system slowly comes back again.
Funny, isn't it?
Actually, it sounds painful. Is your machine paging? (Use 'top' in a
Terminal window and look at the pageouts/pageins.)
The Spin Control was running, but it itself was unresponsive for a
while. After all was running again, the log did not reveal any
usefull - Spin Control did not catch the functions in question and
gave up, since the max hang time expired.
Interestingly, in XCode 1.5 on Mac OS X 10.3.x it seams, drawing
text is about double the fast than in XCode 2.1 on 10.4.x.
That's completely opposite to most of the reports I've heard.
Just an idea, which could be one part of the problem:
In XCode 2.1 many controls get notifications, mainly for updating
states and displaying this in many parts (e.g. status bars) in many
other windows and views.
If there are many windows, dozends of updates are required and also
many notifications.This could be a performance hit in AppKit.
Well, this would really be Xcode's fault not AppKit. But as someone
else mentioned, lots of windows with lots of status bars slows things
down. You can hide them from the View menu. I strongly suggest it.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden