Le 04/04/2016 13:59, Maciej Sumiński a écrit : > On 04/04/2016 12:50 PM, jp charras wrote: >> Le 04/04/2016 01:28, Collin Anderson a écrit : >>> 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! >>> >>> >> >> Thanks for your help. >> I fully agree with you. >> However I am not the guy who wrote the cached container code. >> >> In rev 6661, I disable this deallocation/reallocation option (This change >> was suggested by Orson, >> the author of this code). >> It is not yet perfect. >> >> I still have this issue when switching off/on the Opengl GAL, because there >> is still a >> deallocation/reallocation memory >> >> It could be worth to see if your container class can help to fix this (very >> annoying and serious, >> because I ran out of memory on a PC with 4Gb of memory, with 256 Mbytes >> chunks only) issue. > > @Collin > I am really interested in the results, any performance boost is very > welcome. > > @Jean-Pierre > I have just disabled cached container reallocation on switching between > OpenGL GAL and legacy (rev 6662). It will free the allocated memory when > switching between Cairo and OpenGL, but I think it is reasonable. Please > let me know if it fixes the problem on your hardware. > > Regards, > Orson >
Thanks. I'll test it. -- 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
