[Lazarus] Console App Development

Martin lazarus at mfriebe.de
Sat Aug 13 23:56:13 CEST 2011


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.






More information about the Lazarus mailing list