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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
