kicad-developers team mailing list archive

[Collin Anderson <metacollin@xxxxxxxxxxxx>]

So, I used to be into game development, I was big on writing my own engines from scratch in C++.  This exact memory management problem is one encountered very frequently in such projects.  Any game developer lives by this mantra when it comes to memory management: never fragment the heap.  

The reduction in memory usage cannot justify the system-wide impacts of heap fragmentation and memory manager overhead caused by frequent allocation and freeing of large blocks.  The #if 1 on line 178 should always be a #if 0, in my opinion.  The comment says, 'there is no point in holding a large amount of memory when there is no use for it."  Of course there is a use for it.  There just isn't a use for it right that instant, but if that much simultaneous memory was at one point needed, then its safe to assume it will be needed again, so just hold on to it until then.  Yes, that is wasteful, but it is less wasteful than the system-wide performance toll that significant heap fragmentation can cause.  The reduced memory usage is simply not worth the cost.  It is better to consume the additional memory.

As for improving cached_container, believe it or not, I actually have a container class I wrote years ago that I am rather proud of, it was designed to manage large terrain meshes (I was writing my own ROAM terrain rendering engine) and I am going to play around and see if its adaptable to KiCad.  And if it is, I'll see if it is helpful.  It might be I just THINK it is good, but isn't :).  If I have anything useful to add or modify in that class though, I'll do a branch.  

Thanks!


-- 
"Violence is the last refuge of the incompetent." - Isaac Asimov

> On Mar 29, 2016, at 7:17 AM, jp charras <jp.charras@xxxxxxxxxx> wrote:
> 
> Le 29/03/2016 13:54, Chris Pavlina a écrit :
>> On Tue, Mar 29, 2016 at 09:46:25AM +0200, jp charras wrote:
>>> [[snip]]
>>> But the main reason is the fact on Opengl I am easily out of memory with large boards, with 4Go of
>>> RAM (W7 32 bits).
>>> I am thinking this is due to memory fragmentation.
>>> 
>>> I am afraid we have more easily this issue if Eeschema + Pcbnew + other frames use OpenGL.
>>> 
>>> Cairo do not have this issue.
>>> [[snip]]
>> 
>> Perhaps there is some memory leak or similar issue in the OpenGL GAL code that
>> should be fixed, rather than just avoiding it?
>> 
> 
> It is not a memory leak.
> 
> Currently, very large chunks of memory are frequently allocated and deallocated (256 to 512 Mbytes)
> for large boards by the current code.
> 
> When you are working on such boards, and after editing, running DRC ot 3D viewer, you can be out of
> memory (when the memory is fragmented a lot) to reallocate a block of 256 to 512 Mbytes in RAM, even
> with 4 Gb)
> Remember when closing eeschema, or the 3D viewer or any other main frame, the memory is not free-ed.
> Only frames are closed, but a lot of data is kept in memory.
> 
> Of course, if some other application (for instance Mozilla Firefox, a frequent case) is open, it
> happens more easily.
> 
> To fix it, the algorithm which allocate and deallocate the RAM must be redesigned and/or optimized.
> (see cached_container.cpp), but this is not so easy.
> (In cached_container.cpp, a compil option is added to reduce the frequency of allocations and
> deallocations, and it seriously helps but does not fix all issues)
> 
> 
> Besides, Some Graphic cards have bugs in OpenGL mode (see https://bugs.launchpad.net/bugs/1561928
> for instance).
> 
> Having said that, I am sure there is some memory leak at least in the 3D viewer.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp