On Wed, 16 Jan 2013 22:56:56 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Wednesday, January 16, 2013, Carsten Haitzler wrote: > > > On Wed, 16 Jan 2013 19:30:35 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi <javascript:;>> said: > > > > > On Wed, Jan 16, 2013 at 9:36 AM, Carsten Haitzler > > > <ras...@rasterman.com<javascript:;> > > > > > > wrote: > > > > On Wed, 9 Jan 2013 10:11:37 +0900 Cedric BAIL > > > > <cedric.b...@free.fr<javascript:;>> > > said: > > > > > > > >> Yop, > > > >> > > > >> On Wed, Jan 9, 2013 at 7:13 AM, Gustavo Sverzut Barbieri > > > >> <barbi...@profusion.mobi <javascript:;>> wrote: > > > >> > Quick review: > > > >> > > > > >> > - Eina_Cow_Ptr should be before given memory to user. > > > >> > - It would enforce alignment (as user memory could be not > > aligned). > > > >> > Eina_Cow_Ptr itself is always aligned because it contains pointers, > > so it > > > >> > will not impact what follows. > > > >> > > > >> Eina_Cow_Ptr doesn't have a pointer in it. > > > >> > > > >> > - It would be less likely to suffer from out-of-bounds > > writes... > > > >> > that are VERY common bug :-P > > > >> > - Please use a macro to get Eina_Cow_Ptr from memory. > > > >> > > > >> Indeed. > > > >> > > > >> > - Eina_Cow_Ptr should have magic header... will consume more > > memory, but > > > >> > it's a valuable way to avoid errors with users giving invalid > > pointers > > > >> > > > >> Hum, as Eina_Magic can be disable. Sounds good to. Does the release > > > >> profile disable Eina_Magic, btw ? > > > > > > > > it'd be fine if: > > > > > > > > 1. its separately disableable compared to object magics... so ucan keep > > > > object magic no's and disable cow magics > > > > 2. we need eo id's with special memory space allocation of eo object > > data > > > > outside of normal malloc space so the chances of a memory > > override/scribble > > > > over another object are nigh 0. at this point magic numbers become > > moot as > > > > the object id/table pretty much replace the need safely... > > > > > > The problem is that this API is not private to eo, evas or edje. It's > > > in eina, with a fancy name... then people start to use it and problems > > > will show. > > > > > > Again, the same problems I listed for eo: we need to handle the > > > bad/wrong cases when we think about an API. > > > > the whole point of this is as a deep and ugly way to optimize unused or > > static > > regions of objects. it's basically an object structure aware runtime > > compressor/de-duplicator... you are going to have to be careful when > > using it no matter what. i seriously doubt it will be used by anyone in > > general > > beyond a few very specific cases through efl core itself where we know for > > sure > > we have gains in de-duplication WORTH the cost/overhead/complexity of > > something > > like COW. > > > > I got the idea already. That's not the problem. > > > > > This COW API is bad as I've listed in many places in this thread. I'll > > > just shut up as I'm not being listed, but at least I've replied to a > > > more "official" media... last time I've complained to people at IRC > > > and eo problems leaked and we're suffering now... yet people said > > > "nobody complained". > > > This time I'm complaining, the eina_cow is error prone and > > > confusing/misleading in its method names (ie: the memset). > > > > maybe we should talk about its purpose rather than nitpick the api? to be > > honest i suggested cedric implement this entirely inside of evas to start > > with > > and not make any "eina api" from it. prototype it first. see if it actually > > helps or not with at least the most obvious use cases. sort out a usage > > pattern > > where you can do it without making it a "supported api" so you can nuke it > > if > > needed ro redo it. > > > Your approach is WAY more sensible. It would be completely fine for me. > Doesn't need to be EAPI, we can change as needed, etc. at this stage also gains are "in theory"... still.. in THEORY we will save memory - math-wise this makes sense. it depends a lot on "real life data" though. also it adds overhead of having to manage this and have extra indirections... that comes at a cost... is the cost worth it. only thing i worry about with magic numbers is - now an attempt to lean down mem usage with some really evil methods bloats things out - so the "cost vs benefit" bar moves and moves against doing COW at all... at which point i am wondering if it is worth doing at all. i'd rather not go down the path of magic numbers and so on until: 1. we know there is a real measurable win and what it is "in real life". 2. we have a good idea of the real life downsides. this requires some experimental hacking. tbh i dont care if cow is in eina or not atm... BUT it's api should not be a supported stable one advertised to anyone outside of internal efl use UNTIL we have a good handle on what this api is.. how it should work and if it is even useful in the end. :) that means if it stays in eina - it is not included in Eina.h - its a SPECIAL extra include with nice big fat comments of "don't use this or else we will kill you" :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
