• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Editor Performance Issue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Editor Performance Issue


  • Subject: Re: Editor Performance Issue
  • From: David Ewing <email@hidden>
  • Date: Thu, 5 Feb 2009 12:08:23 -0700


On Feb 4, 2009, at 10:50 AM, Chris Espinosa wrote:

On Feb 4, 2009, at 9:08 AM, email@hidden wrote:

I've been having this issue for several versions of Xcode and am wondering if a) anyone else has this, and b) if there is a fix.

When I type a #include statement in my C++ code and then start typing the file name, Xcode tries to suggest file names as I type - that's great and exactly what I want. However, it sometimes (often) take a very long time (5-10 seconds) to start "suggesting" file names. And, of course, the editor is frozen in the meantime (spinning beach ball). It's so bad that I usually just type the file name first, cut it to the clipboard, then type the #include and paste the file name.

This happens on each of my systems (iMac Core 2 Duo, MBP Core Duo, PowerMac Dual 2.7GHz). I can't tell if it's a CPU loading or disk loading issue - the both seem to be hit really hard when it's formulating its file name suggestion.

Does anyone else have this issue?

Is there anything I can do to improve the performance? I've tried turning off Predictive Compilation and CodeSense, but it doesn't seem to improve anything.

If the path happens to start with "net", this is a known interaction between Xcode and the Mac OS X file system, where Xcode searches conventional paths for headers (including /) and Mac OS X automatically attempts to mount NFS file services for any reference to /net.


Any other lag or delay could be just witing for the indexer to catch up; enumerating a large or slow device or directory; or a bug. Please take a sample and file it at http://bugreporter.apple.com.

Actually, there is another known issue here. The very first time you try to complete a #import/#include it takes significantly longer as it has to build up its list frameworks, directories, and such. We could do better here. :-( You should only see the delay the first time you try it in an Xcode session. (And actually, much of the info is cached in the kernel, so subsequent runs of Xcode aren't usually as slow either.)


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
References: 
 >Editor Performance Issue (From: email@hidden)
 >Re: Editor Performance Issue (From: Chris Espinosa <email@hidden>)

  • Prev by Date: Re: Help on Stack trace
  • Next by Date: xcodebuild clean -really_clean_everything ?
  • Previous by thread: Re: Editor Performance Issue
  • Next by thread: Re: bug in gcc 4.0.1? ld: duplicate symbol typeinfo
  • Index(es):
    • Date
    • Thread