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 16:19:07 +0200
On 28.07.2005, at 15:41, Mike Jackson wrote:
It seems the Eclipse guys were having this same problem when Tiger
came out. The editor would just get slower over time.
Check out this web page
https://bugs.eclipse.org/bugs/show_bug.cgi?id=95475 for the details.
It seems there is a bug in the ATSUI code that is causing this. Maybe
the same issue, maybe not, thought it was worth mentioning.
Another big deal of time adds AppKit. I ran Shark during XCode did a
release build. There was only a few text output in the Build Results
window in XCode, but nevertheless, 38% of the total time were spent in
Xcode - 56.1% left for the compiler
22% within AppKit (_handleWindowNeedsUpdate()) just updating the views
due to the compiler output. In this case, ATSUI code wasn't noticeable
(<0.2%).
8% in CFRunLoopDoTimer.
4.4% shandler.
Andreas
Mike Jackson
On Jul 28, 2005, at 8: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.
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.
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.
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:
email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
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