Re: Speeding up XCode?
Re: Speeding up XCode?
- Subject: Re: Speeding up XCode?
- From: Dietmar Planitzer <email@hidden>
- Date: Mon, 17 Oct 2005 23:22:30 +0200
On Oct 17, 2005, at 8:26 PM, Rob Lockstone wrote:
I don't disagree with you. Xcode, or better yet Cocoa, needs to be
fixed to deal better with large files. However, to date, Apple has
not done very much to improve the situation. I wonder if they've
ever profiled the code internally to see where the hot spot(s) are.
I can't imagine they haven't! I imagine one approach would be to
allow various text editing "bells and whistles" to be optionally
turned on/off. But, I suppose it depends on what, exactly, is
slowing things down.
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.
I've just done a little unscientific test. I took a text file that
contains the disassembler listing of a whole framework. It is 11MB in
size and has 467.747 lines full of PowerPC assembler instructions.
TextEdit needs ca. 2 seconds to open that file on my 1.8GHz dual G5.
You can freely move around with the text cursor using the cursor keys
without any noticeable delay right after TextEdit has finished
loading the file. Jumping to the end of the document by hitting the
document end key results in a ca. 20 seconds pause in which TextEdit
lays out the whole file.
Xcode needs around 2 second to open that file, just like TextEdit.
However, when you try to move around with the cursor keys in the text
file, every key press results in a very noticeable and highly
annoying delay of at least one second. Pressing the document end key
in order to jump to the end of the document results in the appearance
of a progress bar inside the text editor window - which is quite nice
- but also the situation that Xcode goes away for nearly two minutes
until it has finished doing the layout and syntax coloring.
I think I don't need to mention that although Xcode has spent way too
much time (in my opinion) to layout and syntax color the file, the
syntax coloring was (as is usual) wrong. Most hex-numbers were only
partially colored. I.e. the number 0x000045e8 was colored as
expected, while 0x000045d8 was not. This is one of those long
standing bugs where I have given up any hope that it will ever get
fixed.
I personally suspect that the performance problems that the Xcode
code editor has have more to do with the question how the syntax
coloring and symbol gathering mechanism are implemented and
especially how they are hooked into the Cocoa text system, then with
the implementation of the Cocoa text system itself.
Anyway, slowness is an overall problem in Xcode - it's as if it is
supposed to be a feature.
And yes, I also think that the fact that the debugger - after all
those years - still has major problems working reliably and well with
C++ code is supposed to be a feature. I simply no longer know how to
otherwise explain that the debugger still likes to break multiple
lines before or after a breakpoint but not on the breakpoint. Or why
it shows <incomplete type> so often - and especially when you don't
need it. And why it has that annoying tendency of showing the wrong
source code file when it hits a breakpoint.
Let's just say it's all supposed to be a feature...
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