[Lazarus] RE : Console App Development

[Martin]

On 13/08/2011 22:46, Graeme Geldenhuys wrote:
>> IMO ideally we
>> should have only one TSynEdit per window, and just switch "state" when
>> switching tabs.
> If I understood Martin correctly, Lazarus IDE still does processing on
> the other files, so a delay is still to be expected because it is
> single threaded, and the "active tab" is only set and processed at the
> _end_ of processing all the opened files. By processing I mean:
> creating a tab sheet, creating a synedit instance, open and load the
> file.

Threading may archive a speed up here. Because simple you have more CPU 
power at hand. And most OS will be able to supply files faster if 
requested in parallel.

But all the above work, must be finished, before the IDE can hand over 
to the user. See my other mails. If you let the user work in one tab, 
while other tabs are still loading files, then designer forms may still 
open at random. That would really interrupt everyone's work-flow....

>> Also, parsing should be delayed to until the editor (or the TODO
>> window, etc) is displayed.
> I understood that this is already how Lazarus IDE works.
At least for highlighting.

codetools only Mattias can answer. But I believe that some parts of code 
tools only scan on demand, so it may well be. Yet finding a {$R *lfm} 
can not be deferred.

> Don't get me wrong. Yes I mentioned the delay in the tabs when loading 
> 100+ units. But that is not my major concern, because that is not 
> normal daily usage. 
+1 glad we agree


> Though a benchmark is know not to be normal daily usage. My main 
> concern is how greedy Lazarus IDE is becoming with memory. 

Well then someone needs to find out where it goes....

Just testing on windows.
- freshly starting lazarus, automatically re-opens last project:  12 
tabs in 2 source-edit windows => 49.8 MB memory
- adding the 450 univint files => 205.1 MB
    the files contain 16.7 MB actual data
   Also noting that drag and drop opening of multiply files is slower, 
as there is an Begin/EndUpdate missing
- yes closing pages doesn't close free much memory at all
   Not even closing the project

It goes down to 201.9 MB
Interestingly it hasn't even freed the 16.7 MB of raw data.
So part of this must be the memory management. Why? Because:

I know for fact that the synedits get destroyed. At least last time I 
worked on it, the did get destroyed, so unless there is a real huge new 
bug....
If the SynEdits get destroyed, then the textbuffers get destroyed too, 
including the strings containing the text (one string per line, and I am 
pretty sure no other part of the IDE has a ref count on any of them.)

So the memory is probably available, but due to fragmentation, and small 
pieces still being allocated, it can't be returned to the OS.