On 13/08/2011 22:19, Graeme Geldenhuys wrote:
Obviously the speed isn't constant. New features get added, the may take
time while loading.
New features don't always need to mean slower and more memory hungry.
Just look at Mozilla Firefox project. The last few versions came with
new features, but also with speed improvements and less memory hungry.
So it is possible. :)
OT: at least say (fireforx) say so. For my way of using it, it hasn't
changed a bit...
Anyway, I did not say, that all new feature mean a slow down. Some may
do however. Even if they are fast in them self, if additional work needs
to be performed, it will take time or memory or both.
That does not conflict, with the ability to speed up other existent
code. As I equally told you have happened:
- since 0.9.28: All highlighter scanning except the visible tab, have
moved to idle time, instead of start up time
- after 0.9.30: project management of open files has a hash or tree
structure, instead of linear search.
Both of them where very noticable speedups. I do not know if part of the
gained speed was lost to other additions since 0.9.28. But if you whis
you can always get yourself a 0.9.28 and do the test.
Other speed ups, unrelated to project loading have also been made. One
that comes to mind was codetools checking for files modified on disk =>
which could stop the entire IDE for half a minute, because filefunctions
on windows seem to be magnitude slower than linux.
So as far as I can see speed is watched, where it has an impact on
normal use cases.
But I am not sure how high the priority is of getting speed to win a
benchmark (there is plenty other, better stuff to be done)
or getting faster only. Then many features could never be added (your
elastic tabs, if ever done, might mean a slow down... / though that falls
under the deferred-to-idle scans).
I've seen implementations of Elastic Tabstops (ET) that are slow and
others that are fast.
I didn't say that they are necessarily slow.
I did say they will mean a slow down => that may be a very minor slow
down, but they will need an amount of time gretaer than zero to work.
And with a very high likelihood, they will need an amount of time
greater than the current tab implementation. So the will mean a slow down
- Loading time of all tabs (eg: when I tested with 100 or 200 units)
You mean between gtk2 and gtk1?
No, between Lazarus IDE and MSEide - how long it takes to create 100
or 200 tabs.
As found out in another msg. MSEide only creates the tabs, but doesn't
load the files.
I don't know if loading the files can even be omitted. After all the IDE
must know if they contain a {$R *.lfm}, in order to decide if a form
needs to be loaded in the designer.
Sure you could save it in the session, and hope that never an update
from svn/git does change a file to suddenly have a form...
But I am not sure someone is going to rewrite the entire project
management/loading, only to win a benchmark.
- tab / editor screen update. The editor was "blank" for the duration
of loading
The "blank" is partly intentional. Older lazarus did add tab by tab,
updating tabs that wouldn't even be displayed. there was no point in that.
That change was made in the IDE, affecting all widgetsets.
Can't you have one tab as active, and add more tabs without changing
the active tab? Does LCL always set focus (active tab) to the newly
created tab sheet? That's what it looks like to me (when I tested
Friday at work).
I don't know enough about that, and it may depend on the widgetset too.
maybe windows, or gtk are forcing it?
But even if, then if you allowed the user to start editing, and all the
sudden new forms open in the designer.... not useful at all
and again: I doubt it is worth the amount of work it requires. It
certainly isn't to me.
I've got a for (or maybe five) year old computer, with a Intel Dual core
6600 2.4ghz CPU. It takes 16 seconds for 450 files.
I don't know if anyone has such a number of files open in real life, you
can't maintain them anyway, you never find a file through the tabs, and
neither through any menu.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
