Re: XCode editor intolerably slow
Re: XCode editor intolerably slow
- Subject: Re: XCode editor intolerably slow
- From: Andreas Grosam <email@hidden>
- Date: Thu, 28 Jul 2005 20:44:46 +0200
On 28.07.2005, at 17:38, David Ewing wrote:
On Jul 28, 2005, at 6:14 AM, Andreas Grosam wrote:
Just did this: saving a file having 25k lines took about 18 seconds.
I investigated this problem and figured out that almost all time will
hass been spent in updating the editor view.
More precisely, it are mainly member functions of these Cocoa classes
which format text to display it in the editor:
NSLayoutManager, NSATSTypeSetter.
This is the regression that I referred to earlier. The fix will be in
the next update.
Note, that updating the editor view not just occurs when saving
files, it occurs frequently.
These slow text format functions also severely affect drawing of the
function popup - or just anything which displays text.
But not just drawing of text is slow. The indexer (or whatever) takes
about 1 minute to evaluate the symbols for the function popup.
When clicking on it, each time it takes additionally about 10 to 15
seconds to format the text until it opens finally.
It seems very unlikely to me that the slowdown is actually in the
function popup parsing code. (Not that that really matters to you.
Slow is slow.) The scanning doesn't happen when you click on the
popup, it happens in the background. It would be great if you could
get a sample of this happening, and send it to me. It's probably
easiest to do this using Spin Control.
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?
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...".
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?
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.
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.
Regards
Andreas
If you wonder why and how in the hell I have such big sources, :-)
just preprocess a file and you will get it.
But be carefully, I can not recommend to load files bigger than that,
because XCode may stall for several minutes.
We certainly understand that we've got more work to do with source
files bigger than a few thousand lines. We're working closely with the
AppKit folks to make this much faster. But a stall of several minutes
is something that I haven't seen in more than a year. Could you please
send me more details about the specific case you're seeing.
Dave
Hope this helps
Regards
Andreas
On 28.07.2005, at 00:12, David Ewing wrote:
On Jul 27, 2005, at 10:34 AM, Jerry wrote:
On 27 Jul 2005, at 16:57, Kent Sorensen wrote:
While I'm sure this subject has been discussed before I am now so
annoyed at XCode that I have to vent a bit.
I've converted my fairly large project from CW recently and I'm
not pleased at all. I have seen more spinning beachballs these
past weeks than I have ever seen before. Clicking on a search
result - beachball, clicking on a breakpoint to turn it off -
usually beachball and I could go on and on.
The dog-slowness of the editor is severely interfering with
productivity. I have of course already turned off every feature
that might otherwise have made the XCode editor marginally cool,
like indexing, code completion etc.
Many of my files are large at 3-5K+ lines and there are many of
them. Chopping them up is not an option I want to pursue.
My machine is a PBG4/667MHZ 512MB and a fast internal harddisk.
Not top of the line by far, but under CodeWarrior every editor
operation is _instantaneous_ on that machine. It has always been a
pleasure to take the machine to a coffee shop and work remotely
for a few hours. That is no longer the case.
I would like to petition the XCode managers to deliberately _deny_
their developers faster machines than say a Mac mini. Tell them
not to come back before XCode runs well on that machine. I find
the current state of XCode pathetic.
I can live with the abysmal compile speed but for heavens sake
concentrate on the editor for next version.
I have to agree. Using XCode 2.1 means spending a large part of the
day staring at the whirling fruit gum of doom. It often just goes
unresponsive for a minute or two at a time for no apparent reason
and I've learned to stand up and have a bit of a stretch instead of
sitting there waiting for it to come back. Many operations seem
positively glacial - it often takes several seconds for the Windows
menu to appear when you click on it, double-clicking on an error in
the project view takes about 30 seconds before the file appears,
closing a window takes several seconds, and I always grit my teeth
when Command-clicking on a symbol because it can take minutes of
spinning beachball before anything happens. This on a dual G5.
XCode 2.0 wasn't too bad - XCode 2.1 seems to be a step backwards
in this regard.
We know of one regression in 2.1 that can cause spins when saving a
file (and it's fixed for the next version). But it sounds like there
are other things going on as well. When you see performance issues
like these, get a sample of Xcode and file bugs. We really want to
make it snappy. It's also worth running top and make sure your
system's not swapping. 512MB should be plenty of RAM for Xcode by
itself, but if you're running lots of other apps, memory will be
tight, and performance will suffer.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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
_______________________________________________
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