Re: Speeding up XCode?
Re: Speeding up XCode?
- Subject: Re: Speeding up XCode?
- From: Dietmar Planitzer <email@hidden>
- Date: Wed, 19 Oct 2005 11:17:08 +0200
Although I originally wrote the text below in reply to another person
off-list, I repeat what I wrote here as it also fits very well as a
reply to what Stefan said.
On Oct 18, 2005, at 3:14 AM, Stefan Werner wrote:
I personally don't think that Cocoa's text system is the cause of the
performance problems that the Xcode code editor has. First of all,
the fact that Xcode really manages to make _everything_ slow, and be
it as trivial stuff as resizing a project window, is already a good
way to show that Cocoa is not necessarily the problem here.
Actually, the Cocoa text control is the source of the editor's lag.
A quick Shark test will show you that (just let Xcode preprocess
a nicely templated C++ file that includes <Carbon/Carbon.h>
to get a nice test case of a large text file), just like it will show
you that the beachball you see after changing a build setting
in a project with a couple of 100 files comes from Xcode's
dependancy analysis (if I understand the function names correctly,
that is).
Well, I've not only sharked Xcode but also TextEdit. Sharking Xcode
alone is not very helpful in understanding what the reason for the
slow performance of the code editor is, as naturally the fast
majority of the samples that Shark takes are in the area of
NSLayoutManager, NSTypesetter and CoreText aka the routines of the
Cocoa text system that deal with text layout. However, this doesn't
tell us the reason why so much time is spent in doing the text
layout. Although that is in my opinion the more important question to
pose. Why is Xcode spending so much time doing text layout,
especially when compared to TextEdit ?
Why do I constantly bring TextEdit into play here ? I do this because
TextEdit is a very thin wrapper around the Cocoa text system. It, so
to speak, gives us a pure view of the Cocoa text system and its raw
performance. With TextEdit we can find out what the achievable
performance is. With Xcode we can't because Xcode adds a number of
things atop the Cocoa text system. Things like syntax coloring,
symbol gathering or the auto completion stuff.
So, let's look back to my findings from my original post: opening an
assembler listing with 467,747 lines of code in TextEdit and forcing
TextEdit to lay out the whole file takes 20 seconds. This means that
the Cocoa text system is capable of laying out roughly 23,000 lines
per second. I don't know about you people, but for me this is good
enough for a code editor.
Now, opening the same file in Xcode and forcing again a layout of the
whole file takes Xcode a bit over 2 minutes or more than 120 seconds.
Thus, Xcode is around 6 times slower doing the layout of the same
file as TextEdit. Or expressing this again in terms of lines per
second, Xcode is able to lay out around 3,800 lines per second. That,
however, is not good enough since even the average QuickTime or
Carbon header has already somewhere between 10,000 and 20,000 lines.
I'm sorry, but explaining the large discrepancy between the layout
speed of TextEdit (pure Cocoa text system) and Xcode (Cocoa text
system + syntax coloring) with an inherently slow Cocoa text system
does not work in my world. This is why I suspect that the cause of
the big slow down in the case of Xcode has more to do with the way
that the syntax coloring mechanism is hooked into the text system
than the text system itself. More specifically, I suspect that the
syntax coloring mechanism is causing too much or too often the
invalidation of the layout information computed and cached by
NSLayoutManager. But this is just an assumption as I obviously have
no access to the Xcode sources.
Then there are other reasons why I rather blame Xcode than the Cocoa
text system:
First, I've kept an eye over the past years on how the performance of
the Cocoa text system has been developing. What I have been able to
observe, was that the performance of the Cocoa text system has been
steadily improving. In fact there was a big jump in speed between
10.2 and 10.3 and another big speed increase from 10.3 to 10.4.
However, the speed of the code editor in Xcode and before that
Project Builder and before that ProjectBuilder has been steadily
going down over the same time span.
I mean, don't take my word for it. Go grab a Macintosh - a G4 with
around 400MHz works especially well for this - and install Mac OS
10.0 up to and including 10.4. Then take TextEdit and open the same
file in each version and play around with it. You will notice that
the younger the system version, the higher the text editing speed in
TextEdit is. Now do the same with Xcode and its predecessors. You
will notice that the younger the system version is, the slower the
Xcode code editor is.
So, what we have here is one application that is using the Cocoa text
system which has a speed curve that has been increasing from year to
year. On the other side we have an application that is also using the
Cocoa text system, but where the speed curve has been decreasing from
year to year. Thus, putting all the blame on the Cocoa text system is
at odds with this observation.
Another point to keep in mind is that Xcode, as I already said,
manages to make everything slow no matter how trivial the operation
is. Again, don't take my word for it - try it on your own. Resizing a
project window in Xcode is noticeably slower than doing the same with
the windows of other applications. Activating an Xcode window or
deactivating an Xcode window is noticeably slower than doing the same
in other applications with and without tool bars.
Why should I assume that an application where everything is slow,
would suddenly have an extremely well implemented and fast syntax
coloring mechanism ? Given the precedence established by the rest of
the application there is no reason to make such an assumption.
Finally, there is another observation that I have been able to make
while monitoring the progress of Xcode and its predecessors: There
were at least four events in the history of Xcode where each of them
has resulted in a very noticeable slow down of the code editor. Those
events were, in no particular order, the introduction of syntax
coloring, the symbol pop-up menu, the forced multiple editor
instances and auto-completion. In every single case, the editor
performance went down when compared with the previous version.
Regards,
Dietmar Planitzer
_______________________________________________
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