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 14:14:25 +0200
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:
This email sent to email@hidden