[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] eo stability - i think we need to postpone that
From:       Tom Hacohen <tom () osg ! samsung ! com>
Date:       2015-09-28 17:43:58
Message-ID: 56097C5E.6080907 () osg ! samsung ! com
[Download RAW message or body]

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.

--
Tom.

------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]