kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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