Re: XCode editor intolerably slow
Re: XCode editor intolerably slow
- Subject: Re: XCode editor intolerably slow
- From: Andreas Grosam <email@hidden>
- Date: Sat, 30 Jul 2005 14:16:03 +0200
On 28.07.2005, at 22:10, David Ewing wrote:
David,
i did more testing and investigated this issue using Shark. Spin
Control does not always reveal the problem in detail. It also turned
out that it is not that simple to figure out where the problem is. So i
really would appreciate it if you would do the same, since it is
difficult to mail you my results - or even explain all that.
What i suspect is that
1) there is not only one problem, there are several causing performance
hits.
2) one of it is NSLayoutManger - it seems, there is a serious flaw.
Laoding a 5MB file, takes minutes. 80% is spend somewhere in
NSLayoutManager, NSATSTypesetter,
20% is spend in the PBXStringLexer.
(Note, in CW it takes about 2 seconds to load that file, that is CW is
about 100 times faster)
Clicking into the function popup takes about 3 seconds till it opens.
50% of the time is spent in ATSUGetGlyphBounds.
(in CW this takes about <0.5 secs)
Switching syntax coloring on and off, takes minutes.
90% NSLayoutManger/NSATSTypeSetter; from that 30% in LLCLayoutText.
After i turned syntax coloring off, XCode was pretty unresponsive when
trying to scroll the text, editing or selecting text (a delay of 3 ..15
seconds).
(Note, in CW switching syntax coloring happens almost instantly)
This last behavior let me assume that there is a bug in
NSLayoutManager. Furthermore, for some reason, much of the time is
spend in CF dictionaries (during NSLayoutManager), which is really
strange (probably, a huge amount of entries??)
When syntax coloring was on again (which again took minutes), the
XCode editor was responsive enough again.
Note, the problem becomes more obvious, when we use a bigger file. For
my tests i used a 150k lines file (about 5MB). With this file, i got
sufficient large delays (minutes) to investigate this with Shark.
Another hint: I got not only delays, but also a total hang of the
system, as i switched the treshhold font size for smoothing text in the
preference panels. XCode had this big file open, begun to spin the
pizza, and suddenly all froze to death.
Note, all tests with XCode 1.5, and 10.3.9.
XCode 2.1 is even worser.
I would appreciate that folks at Apple would investige this in more
detail.
Regards
Andreas
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