Hello Tom,
On Wed, Oct 14, 2015 at 6:41 PM, Tom Hacohen <[email protected]> wrote: > On 28/09/15 18:43, Tom Hacohen wrote: > >> On 10/07/15 04:27, Carsten Haitzler wrote: >> >>> it has come to my attention that we have a bit of a memory bloat issue >>> with eo. >>> >>> and that has to do with eo at runtime doing things like: >>> >>> _eo_class_funcs_set() >>> >>> read it. loop over all ops int he op desc table (array) foir the class >>> then go >>> MODIFYING the array - setting pointers >>> >>> op_desc->op = op_id; >>> + >>> op_desc->op = api_desc->op; >>> op_desc->doc = api_desc->doc; >>> etc. >>> >>> now here is the rub. across a LOT of classes, we will have 50, 100+ of >>> these >>> arrays. each one will maybe span 1-2 or maybe 3 pages of ram, this is RW >>> memory >>> coming from the lib and every single app goes duplicating this then >>> modifying >>> these pointers to be THE SAME THING in each process. >>> >>> first problem - the modified bits vs static bits are spread out. thus we >>> may >>> modify only 1 or 2 ptrs per item in the array, but the whole array spans >>> a fair >>> bit of memory and thus... we end up modifying multiple pages of memory >>> .. per >>> library etc. - this adds up quickly. maybe 40-80kb per process. then this >>> multiples by the number of processes we have using efl. that's costly. >>> >>> we need to fix/adjust this so it can/is set up at COMPILE TIME with a >>> bunch of >>> consts. eolian needs to take care of this. >>> >>> catch - eo allows runtime dynamic overriding of a class. you can >>> literally >>> generate it and modify it as you please at runtime based on current code >>> paths. >>> we still would like this to work. so we need to have 2 paths. 1 where we >>> pre-fill a class at compile-time all cosnt'd out, then to override at >>> runtime - >>> duplicate to non-const version then modify at will. >>> >>> the catch here is - to do these fixes will mean breaking eo abi. i'm >>> looking at >>> it now and i can't see an alternative there. >>> >>> so first - we need to hold off on calling eo stable. then fix this. this >>> doesn't stop interfaces work - it just means we have extra to do. >>> >>> >> Finally got around to it. Fixed now. Please take a look and tell me if >> you see anything bad still. >> > > OK, wow. This has been very annoying. :P > It's definitely fixed, though for some reason all of my tests to verify > this have failed until now. Now everything finally shows the correct > results. More specifically, I can see the improvement in clean vs dirty > pages when running: pmap -p -XX `pidof elementary_test`. > I attached the full pmap output from before and after my fix, just an > example for elementary, private clean and private dirty: > Clean Dirty > Before: 0 2336 > After: 2224 0 > > An obvious win. > > Thanks again to Carsten for noticing this. This is something that slipped > in Eo2 (was OK with Eo1) and almost went unnoticed. > > This is great. :) and I am sure fixing this had been fun. ;) I am curious to know how did you fix it? Whenever you get time, please do list out the relevant commits, so that I can relate things. I did some reverse engineering before (during college days) so can pick up this quickly. :) -- > Tom. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
