Agreed. My compiled app is pretty much as fast as it was compiled
under 5.5.5. The problem seems to be an exponential slow down in the
IDE based on number of methods and properties in an open class.
I have three classes (out of 350) that have several hundred methods
and properties (one being an enormous RBScript context class, which
can't be refactored since you're only allowed one context). I'm
refactoring the other two classes, and they are slooooowwwwwly
getting faster to edit. It takes, for example, 25 seconds to do
Edit->Cut on a property so that I can move it elsewhere. However, two
days ago it took 30+ seconds. Woo hoo. I'll be finished by 2007r2...
(I won't mention having to restart the IDE every 30 mins when the
number of uncaught exceptions gets too big - this IDE is riddled with
bugs. Living proof that RS must still be on a diet of 3rd party dog
food).
Another fact that points to the IDE code being dodgy: Edit->Cut on a
property with a name starting with "A" is much faster than one at the
other end of the list. I'm considering calling all my properties
"AARDVARK1", "AARDVARK2", etc. :^)
With due respect to RS, I have to confess that parts of the IDE don't seem
to have a good underlying architecture. I really have to wonder why editing
a class with, say, 250 methods should take any more time than one with 2
methods if the underlying data representation is correct, whether in RAM or
on disk. Why should selecting and copying method 250 take longer than method
1, and why should either take a noticeable amount of time? Why should typing
in a method in said class of 250 methods be more sluggish than a class with
10?
The only thing I can think of is that the auto complete cache is struggling
to keep up. It really shouldn't be though.
The forms layout seems like it could be better as well, though seeing the
difference between Mac and Windows here makes me think half the problem on
the Mac is simply Quartz. You have to work pretty hard if you want Quartz to
behave any better than an old bus at a stop light.
The plugin cache rebuild is horrendous and always has been. I've been
looking at the resulting cache files trying to understand what is being
copied/converted/stored there. There *has* to be a faster and more memory
efficient way to build those files. There just has to be. At this point,
after changing plugins, I have to build each target by itself, and
quit/relaunch in between builds, or the plugin preparation fails. All I've
got is MBS and a handful of items from Einhuger. (OK, MBS is huge, but
still.) RB2007r1 ends up needing about 1 GB during the prep and consumes
every drop of resources my dual core machine has to offer. It's so bad I
have to wonder if the underlying functions thrash static strings (i.e.
dataStringA + dataStringB, loop a billion times for lots of memory copies).
FWIW, RB is hardly the only app where I have speed complaints. I really,
honestly wonder why I have to wait for many tasks in many programs on a CPU
that performs billions of ops per second.
Daniel L. Taylor
Taylor Design
Computer Consulting & Software Development
[EMAIL PROTECTED]
www.taylor-design.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
