[Lazarus] RE : RE : RE : RE : RE : Console App Development

[Ludo Brands]

> 
> I think the above may have been lost in the rest.
> 
> yet, while you certainly have a point. It isn't proof. it could be 
> argued fragmentation based inability to re-use. Though I accept the 
> lower likelihood of it.
> 
> Yet at least part of it may be.
> I tried the process about 20 times (on windows). The first 4 
> or 5 times 
> the increase was big, it then however decreased, and at the end there 
> was very little further increase, when adding the files again, and 
> removing them (memory would be higher while they where added, but for 
> each cycle the memory would go down as well)
> 

I'm noticing also a "slow down" in memory consumption after 5-6 unload/load
cycles.

I compiled Lazarus with cmem to be sure valgrind massif recognises correctly
the memory manager: results are very similar. So the probability that memory
isn't returned by the program (vs memory manager) is growing. 

So far I have been concentrating on the memory usage before and after
closing the 450 files. I'm now concentrating more on what increases when
unload/load the 450 files since that would really be the "bad" memory.
Interesting finding so far: 
- the gutter images don't increase, nor do the codecaches mentioned before.
They stay in memory but apparently are reused. 
- a big memory chunk that grows is memory allocated by pthread_create called
from Qthread::start.  The stack trace mentions QFileSystemWatcher::addPath,
IBusPlugin. I mention QFileSystemWatcher and IBusPlugin because after a lot
of testing, Lazarus failed to start with an error
QInotifyFileSystemWatcherEngine::addPaths: ,inotify_add_watch failed. I had
to reboot the system. The threads created are all shortlived (I can't find a
lot of threads attached to Lazarus). I read somewhere that pthread releases
resources when pthread_detach or pthread_join is called, not after a
pthread_exit. This could explain resources held back for threads not running
anymore, and nicely released when the program finishes. This is probably Qt
specific. But, the same stack trace also shows that
CUSTOMFORM_SETWINDOWFOCUS causes 1/3 of the Qthread::start. I'm surprised
that loading multiple files in an editor should move focus to every window.
Another 1/3 is triggered by TMENU_ITEMCLICK triggering much later a
QFileDialog_create. Is that how files are loaded?  

I'll look further into this.

Ludo