Re: [E-devel] Shared Strings
Cedric BAIL schrieb: > > I think we didn't understand together. When I say slowly move stuff > around, it include changing and improving Eina to fit our needs also. > Eina is not a finished library, but an ongoing development. It's just > a good starting point imho to get stuff done faster. > Ok, then I really misunderstood you. I thought you want to throw it in to cvs and porting evas to use it immediately. If I understand you now right, you want to put it into cvs (maybe in proto), bringing it in shape and once it is finished, i.e. as we want it. You'll go to port evas et al. to it. > >> For example in eina the evas_hash implementation is called eina_hash. I think >> it'd be better to reserve this name for the ecore_hash implementation, >> because >> it is much more general. For the evas_hash implementation another name like >> eina_strhash would imho then be better. >> > > I agree with your rename it make sense. But I still think that doing > this review with the code in CVS would be faster. Instead of just > discussing we will have code progressing at the same time and every > one following development on the CVS will be able to participate in > this review and get stuff done faster. > > >> And I'm still not convinced if there is a general need to have a >> fixed-point implementation in the base data types lib, just to mention my >> concerns. Maybe someone else, with more authority then me :), will join this >> discussion. >> > > In my opinion, it's easier to remove code than to write :-) I don't > see any direct user for this feature right now, but with the planned > evolution of evas, their could be some. So I d > > Not if apps/libs already depend on it :) >> I'm sure turran took care in doing eina, but you'll get more agreement if >> things are discussed before. >> > > The idea of moving eina inside the efl librarry CVS repository is to > take care of it as a group and use this as a fast starter. It's a lot > of work to move data type out of Evas, preserving speed, feature and > stability. So that what we win by using eina as a starting point. Then > as a group we can change and update this stuff according to our need. > I am sure Turran will agree on this. > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Fri, Jul 11, 2008 at 11:11 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Cedric BAIL schrieb: Putting eina now into cvs doesn't help anyone at the moment. There are two ways we can go: 1. First we start with a little lib, where we put step by step code into it, we agree with that it belongs into the common lib. That's what I tried with edt. 2. We first discuss how the common lib needs to be en bloc and in detail and then change eina to match the result of the discussion. And move it then into cvs. It looks like most people here prefer the second way. >> I will say we have a third option. Put a common lib in cvs now. Then >> slowly move stuff around to the new system. With current work from >> caro with Evas_Data.h we should be able to provide a set of macro that >> will help do the move quickly. This move should not impact performance >> at all (and looking at eina current code, I don't see how it could >> change something regarding that). > With focus on evas this is right, but you would be going to make facts > without discussing them before. I think we didn't understand together. When I say slowly move stuff around, it include changing and improving Eina to fit our needs also. Eina is not a finished library, but an ongoing development. It's just a good starting point imho to get stuff done faster. > For example in eina the evas_hash implementation is called eina_hash. I think > it'd be better to reserve this name for the ecore_hash implementation, because > it is much more general. For the evas_hash implementation another name like > eina_strhash would imho then be better. I agree with your rename it make sense. But I still think that doing this review with the code in CVS would be faster. Instead of just discussing we will have code progressing at the same time and every one following development on the CVS will be able to participate in this review and get stuff done faster. > And I'm still not convinced if there is a general need to have a > fixed-point implementation in the base data types lib, just to mention my > concerns. Maybe someone else, with more authority then me :), will join this > discussion. In my opinion, it's easier to remove code than to write :-) I don't see any direct user for this feature right now, but with the planned evolution of evas, their could be some. So I d > I'm sure turran took care in doing eina, but you'll get more agreement if > things are discussed before. The idea of moving eina inside the efl librarry CVS repository is to take care of it as a group and use this as a fast starter. It's a lot of work to move data type out of Evas, preserving speed, feature and stability. So that what we win by using eina as a starting point. Then as a group we can change and update this stuff according to our need. I am sure Turran will agree on this. -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Cedric BAIL schrieb: >>> Putting eina now into cvs doesn't help anyone at the moment. There are two >>> ways we can go: >>> >>> 1. First we start with a little lib, where we put step by step code into it, >>> we agree with that it belongs into the common lib. That's what I tried with >>> edt. >>> 2. We first discuss how the common lib needs to be en bloc and in detail and >>> then change eina to match the result of the discussion. And move it then >>> into cvs. >>> >>> It looks like most people here prefer the second way. >>> > > I will say we have a third option. Put a common lib in cvs now. Then > slowly move stuff around to the new system. With current work from > caro with Evas_Data.h we should be able to provide a set of macro that > will help do the move quickly. This move should not impact performance > at all (and looking at eina current code, I don't see how it could > change something regarding that). > With focus on evas this is right, but you would be going to make facts without discussing them before. For example in eina the evas_hash implementation is called eina_hash. I think it'd be better to reserve this name for the ecore_hash implementation, because it is much more general. For the evas_hash implementation another name like eina_strhash would imho then be better. And I'm still not convinced if there is a general need to have a fixed-point implementation in the base data types lib, just to mention my concerns. Maybe someone else, with more authority then me :), will join this discussion. I'm sure turran took care in doing eina, but you'll get more agreement if things are discussed before. Regards, Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Jorge Luis Zapata Muga schrieb: > On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> Jorge Luis Zapata Muga schrieb: >> >>> Having a common agreement isnt easy but we should make one. Cedric >>> ideas of providing a common API and just do some macros is useful, i >>> agree that the structure of the code using might have to change, but >>> either way a list API of any kind, is more or less common, you iterate >>> over it with the next and prev and you get data, the rest is an >>> extended API. A big effort has to be made from us to port everything >>> on cvs to it, but one time or another this has to be done. >>> >>> >> I don't think that an unification of the list APIs is possible. And even if, >> we'd end up to change thousands of lines of stable code, which was tested >> over many years. And that without any reasonable benefit. >> > > Here you'll find a simple implementation of ecore_dlist using > evas_list as its backend > http://code.google.com/p/efl-research/source/browse the module is > called ee_list, you'll see that not every function is implemented but > enough to see that there's no difference in the API or in the result. > So in my opinion it is possible. Indeed, that way it is possible. > IMHO Is not a problem of possibility > but of will, if we want to have only one double linked list > implementation we should do the effort. Sure it isn't a big deal to write this wrapper and with a little bit more work, it is also possible to support index counting, which I consider as part of the API. > The benefits are several, > beside consistency on the code, is good for newcomers, every time a > new dev come around he asks what list/hash to use and what toolkit, > etk/ewl ? (but a toolkit isnt core, data types are). > That is my main problem with it. I don't see any real benefit doing it. There will be still two implementations (APIs) around, so the new dev will still ask which one to use. And sure you will share code between ecore_dlist and evas_list, but ecore_list and ecore_dlist are sharing code already, this overlap will then be lost. On the other hand you will increase the node size by one pointer without having any improvement, except maybe the mempool mentioned by cedric. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Not directly related to shared-strings or data structures, but as a relevant aside to the more general issue of useful 'core' kinds of libs, there is one lib that Jorge and Hisham recently worked on that might be of interest - namely, the timeline based animation lib "etch". I'm not sure just how finished that might be or whatnot, but I did see a video that Hisham sent me of it being used to animate an etk widget moving around and doing other stuff in an etk canvas widget.. and it was pretty nice. :) Summer Spa Sweepstakes Enter for your chance to WIN a Summer Spa Vacation! http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbfFlqaNggsaIGeiSibY7SvTZk96CBWAeILRTlHdeuMfBF/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Wed, Jul 9, 2008 at 2:40 PM, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: >> Jorge Luis Zapata Muga schrieb: >>> >>> Having a common agreement isnt easy but we should make one. Cedric >>> ideas of providing a common API and just do some macros is useful, i >>> agree that the structure of the code using might have to change, but >>> either way a list API of any kind, is more or less common, you iterate >>> over it with the next and prev and you get data, the rest is an >>> extended API. A big effort has to be made from us to port everything >>> on cvs to it, but one time or another this has to be done. >>> >> >> I don't think that an unification of the list APIs is possible. And even if, >> we'd end up to change thousands of lines of stable code, which was tested >> over many years. And that without any reasonable benefit. > > Here you'll find a simple implementation of ecore_dlist using > evas_list as its backend > http://code.google.com/p/efl-research/source/browse the module is > called ee_list, you'll see that not every function is implemented but > enough to see that there's no difference in the API or in the result. > So in my opinion it is possible. IMHO Is not a problem of possibility > but of will, if we want to have only one double linked list > implementation we should do the effort. The benefits are several, > beside consistency on the code, is good for newcomers, every time a > new dev come around he asks what list/hash to use and what toolkit, > etk/ewl ? (but a toolkit isnt core, data types are). I would also add that it will improve memory profile as we will use the same memory pool for all list. >>> eina should be included into cvs, im ok with that, im kind of >>> restrictive to indentation changes, but that's another matter :) >>> >>> In my opinion the first thing that should be done is add the svn code >>> into cvs, then add your stringshare there and slowly port the rest, >>> eet is a special case because it already has a release, so it should >>> depend on another releasable code (eina) which isnt complete, so eet >>> might have to be last one to be ported. >> >> Putting eina now into cvs doesn't help anyone at the moment. There are two >> ways we can go: >> >> 1. First we start with a little lib, where we put step by step code into it, >> we agree with that it belongs into the common lib. That's what I tried with >> edt. >> 2. We first discuss how the common lib needs to be en bloc and in detail and >> then change eina to match the result of the discussion. And move it then >> into cvs. >> >> It looks like most people here prefer the second way. I will say we have a third option. Put a common lib in cvs now. Then slowly move stuff around to the new system. With current work from caro with Evas_Data.h we should be able to provide a set of macro that will help do the move quickly. This move should not impact performance at all (and looking at eina current code, I don't see how it could change something regarding that). -- Cedric BAIL - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Jorge Luis Zapata Muga schrieb: >> >> Having a common agreement isnt easy but we should make one. Cedric >> ideas of providing a common API and just do some macros is useful, i >> agree that the structure of the code using might have to change, but >> either way a list API of any kind, is more or less common, you iterate >> over it with the next and prev and you get data, the rest is an >> extended API. A big effort has to be made from us to port everything >> on cvs to it, but one time or another this has to be done. >> > > I don't think that an unification of the list APIs is possible. And even if, > we'd end up to change thousands of lines of stable code, which was tested > over many years. And that without any reasonable benefit. Here you'll find a simple implementation of ecore_dlist using evas_list as its backend http://code.google.com/p/efl-research/source/browse the module is called ee_list, you'll see that not every function is implemented but enough to see that there's no difference in the API or in the result. So in my opinion it is possible. IMHO Is not a problem of possibility but of will, if we want to have only one double linked list implementation we should do the effort. The benefits are several, beside consistency on the code, is good for newcomers, every time a new dev come around he asks what list/hash to use and what toolkit, etk/ewl ? (but a toolkit isnt core, data types are). > >>> Iirc, there are some things in eina that raster didn't want to have in >>> the data type. I haven't looked into eina lately, but last time i did he >>> >> >> Well, having some subsystems of eina not desirable isnt an excuse to >> have 5 implementations of the same ;) >> > > We have two string pools and the lib I proposed would reduce it to one > implementation. Yes, i wasnt refering to the string pool itself, but to the list and hash, the stringpool already has consensus, but the latter no. > >> >> If stringshare pool already has a common API between ecore an evas >> ones, why not put that on the current effort of a common data type? >> > > I'm not sure if I understand you correct, but that's exactly what edt was > meant for. When i said "current effort" i meant actually the old edata or eina, as it has appeared on the ml and irc several times. > >> eina should be included into cvs, im ok with that, im kind of >> restrictive to indentation changes, but that's another matter :) >> >> In my opinion the first thing that should be done is add the svn code >> into cvs, then add your stringshare there and slowly port the rest, >> eet is a special case because it already has a release, so it should >> depend on another releasable code (eina) which isnt complete, so eet >> might have to be last one to be ported. >> > > Putting eina now into cvs doesn't help anyone at the moment. There are two > ways we can go: > > 1. First we start with a little lib, where we put step by step code into it, > we agree with that it belongs into the common lib. That's what I tried with > edt. > 2. We first discuss how the common lib needs to be en bloc and in detail and > then change eina to match the result of the discussion. And move it then > into cvs. > > It looks like most people here prefer the second way. > >> I think that a good thing to do is to actually compare both API's and >> try (if possible) to merge them, any volunteer? for the simplest use >> cases of course, get a data from the list and iterate over it. >> > > I don't like the two very much, but I believe we have to keep both > implementations. As I said above, I don't think it is worth the effort. And > about merging them, you haven't much space for that, because eet expects a > evas_list-like API. > - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Jorge Luis Zapata Muga schrieb: > > Having a common agreement isnt easy but we should make one. Cedric > ideas of providing a common API and just do some macros is useful, i > agree that the structure of the code using might have to change, but > either way a list API of any kind, is more or less common, you iterate > over it with the next and prev and you get data, the rest is an > extended API. A big effort has to be made from us to port everything > on cvs to it, but one time or another this has to be done. > I don't think that an unification of the list APIs is possible. And even if, we'd end up to change thousands of lines of stable code, which was tested over many years. And that without any reasonable benefit. >> Iirc, there are some things in eina that raster didn't want to have in >> the data type. I haven't looked into eina lately, but last time i did he >> > > Well, having some subsystems of eina not desirable isnt an excuse to > have 5 implementations of the same ;) > We have two string pools and the lib I proposed would reduce it to one implementation. > > If stringshare pool already has a common API between ecore an evas > ones, why not put that on the current effort of a common data type? > I'm not sure if I understand you correct, but that's exactly what edt was meant for. > eina should be included into cvs, im ok with that, im kind of > restrictive to indentation changes, but that's another matter :) > > In my opinion the first thing that should be done is add the svn code > into cvs, then add your stringshare there and slowly port the rest, > eet is a special case because it already has a release, so it should > depend on another releasable code (eina) which isnt complete, so eet > might have to be last one to be ported. > Putting eina now into cvs doesn't help anyone at the moment. There are two ways we can go: 1. First we start with a little lib, where we put step by step code into it, we agree with that it belongs into the common lib. That's what I tried with edt. 2. We first discuss how the common lib needs to be en bloc and in detail and then change eina to match the result of the discussion. And move it then into cvs. It looks like most people here prefer the second way. > I think that a good thing to do is to actually compare both API's and > try (if possible) to merge them, any volunteer? for the simplest use > cases of course, get a data from the list and iterate over it. > I don't like the two very much, but I believe we have to keep both implementations. As I said above, I don't think it is worth the effort. And about merging them, you haven't much space for that, because eet expects a evas_list-like API. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Tue, Jul 8, 2008 at 11:44 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Cedric BAIL schrieb: >> On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: >> >>> Vincent Torri schrieb: >>> I think that Hisham wants you to put your code in edata, and not create another lib. >>> Unfortunately, it isn't that easy. We have two (or with other counting 3 >>> or 4) list implementations and two hash implementations. Since their API >>> is totally different, especially for the lists, we cannot simply choose >>> one of them and port the rest to that API without an incredibly huge >>> amount of work. So the only way we can handle it is to have both >>> implementations parallel in the data lib. But how are we going to name >>> them? Maybe we name the evas_list edt_nodes or we name the ecore_list >>> edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the >>> evas_list. For the hashs the situation is a bit better. After Nathan has >>> his ecore_hash improvements in. We can make the evas_hash a wrapper >>> around it. But we still need to think about a name for it, maybe >>> edt_strhash. Where we can really unify stuff is for ecore_list2 and >>> evas_object_list, i think we can take there turran's eina_inlist. And >>> edata has also an edata_array, what are we going to use evas_array or >>> edata_array, or do we also need both? Besides that I wouldn't put >>> ecore_tree into the new lib before it is fixed, it is currently in an >>> unusable state. >>> >> >> We also have some inthash and we need hash indexed by two int for the >> font subsytem. > Maybe, we can use there ecore_hash, but i don't know if it fits the needs. >> And you forgot the simple hash and list implementation >> of eet :-) Yes, the situation is a bit complex... >> > Yup, i know that it is very complex :), especially if we want to unify > things. Having a common agreement isnt easy but we should make one. Cedric ideas of providing a common API and just do some macros is useful, i agree that the structure of the code using might have to change, but either way a list API of any kind, is more or less common, you iterate over it with the next and prev and you get data, the rest is an extended API. A big effort has to be made from us to port everything on cvs to it, but one time or another this has to be done. >> >>> As you can see there are many open questions, that needs to be answered >>> first. That's why raster had the idea to first put the string pool into >>> the new lib, because - as mentioned before - the API is the same. Of >>> course we still need to discuss what is going into that lib and how. If >>> people prefer to discuss it yet and do the whole stuff later at once, we >>> can do this as well, but just taking edata doesn't work. >>> >> >> But why didn't we just put eina inside the libs cvs directory (svn >> checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And >> start hacking from here. We can then slowly switch evas , ecore and >> eet to the data type eina provide or the one we add to eina. It should >> be easier to start from something with code and hack than agree on >> what we should put in. But if you are going to do the work, I will >> agree and help on this project as it's something we need to do. >> > > Iirc, there are some things in eina that raster didn't want to have in > the data type. I haven't looked into eina lately, but last time i did he Well, having some subsystems of eina not desirable isnt an excuse to have 5 implementations of the same ;) > started to use evas_list instead of ecore_list, the problem is that i > don't think we can choose one of them and then port the rest to that, it > isn't only a different way of API, it also results in a different code > structure and some things aren't possible with the one implementation, > which aren't possible with the other. So i think we have to go with > boths, if we don't want to move the release date into the fare future. > Using both reduce the porting to the new API to a simple sed script. > > I don't think, that it is much work to put things together, the code is > already here, no matter if we take it from evas, ecore, edata or eina. > Some lines of sed, maybe a reindent and then adding it to the > Makefile.am and the header to the Edt.h (or how name it). Yes, i agree. Eina started as ecore data types and then moved to evas data types, is quite easy as you said because the code is already there, of course there are other things useful on eina's code that are interesting for every project ... the rectangle stuff, the error stuff (still proto), the fixed point, the memory pool etc. If stringshare pool already has a common API between ecore an evas ones, why not put that on the current effort of a common data type? eina should be included into cvs, im ok with that, im kind of restrictive to indentation changes, but that's another matter :) In my opinion the first thing that should be done is add
Re: [E-devel] Shared Strings
Hi all, On Tue, Jul 8, 2008 at 12:24 PM, Vincent Torri <[EMAIL PROTECTED]> wrote: > >> But why didn't we just put eina inside the libs cvs directory (svn >> checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And >> start hacking from here. We can then slowly switch evas , ecore and >> eet to the data type eina provide or the one we add to eina. It should >> be easier to start from something with code and hack than agree on >> what we should put in. But if you are going to do the work, I will >> agree and help on this project as it's something we need to do. > > there is already an 'edata' in e17/proto, btw > > Vincent The edata in proto was an attempt i did a long ago to try to unify all of our projects into a common library for data types, sadly no one was interested on making it usable, it was only a copy of evas_data types. > > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
> But why didn't we just put eina inside the libs cvs directory (svn > checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And > start hacking from here. We can then slowly switch evas , ecore and > eet to the data type eina provide or the one we add to eina. It should > be easier to start from something with code and hack than agree on > what we should put in. But if you are going to do the work, I will > agree and help on this project as it's something we need to do. there is already an 'edata' in e17/proto, btw Vincent - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Cedric BAIL schrieb: > On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> Vincent Torri schrieb: >> >>> I think that Hisham wants you to put your code in edata, and not create >>> another lib. >>> >>> >> Unfortunately, it isn't that easy. We have two (or with other counting 3 >> or 4) list implementations and two hash implementations. Since their API >> is totally different, especially for the lists, we cannot simply choose >> one of them and port the rest to that API without an incredibly huge >> amount of work. So the only way we can handle it is to have both >> implementations parallel in the data lib. But how are we going to name >> them? Maybe we name the evas_list edt_nodes or we name the ecore_list >> edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the >> evas_list. For the hashs the situation is a bit better. After Nathan has >> his ecore_hash improvements in. We can make the evas_hash a wrapper >> around it. But we still need to think about a name for it, maybe >> edt_strhash. Where we can really unify stuff is for ecore_list2 and >> evas_object_list, i think we can take there turran's eina_inlist. And >> edata has also an edata_array, what are we going to use evas_array or >> edata_array, or do we also need both? Besides that I wouldn't put >> ecore_tree into the new lib before it is fixed, it is currently in an >> unusable state. >> > > We also have some inthash and we need hash indexed by two int for the > font subsytem. Maybe, we can use there ecore_hash, but i don't know if it fits the needs. > And you forgot the simple hash and list implementation > of eet :-) Yes, the situation is a bit complex... > Yup, i know that it is very complex :), especially if we want to unify things. > >> As you can see there are many open questions, that needs to be answered >> first. That's why raster had the idea to first put the string pool into >> the new lib, because - as mentioned before - the API is the same. Of >> course we still need to discuss what is going into that lib and how. If >> people prefer to discuss it yet and do the whole stuff later at once, we >> can do this as well, but just taking edata doesn't work. >> > > But why didn't we just put eina inside the libs cvs directory (svn > checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And > start hacking from here. We can then slowly switch evas , ecore and > eet to the data type eina provide or the one we add to eina. It should > be easier to start from something with code and hack than agree on > what we should put in. But if you are going to do the work, I will > agree and help on this project as it's something we need to do. > Iirc, there are some things in eina that raster didn't want to have in the data type. I haven't looked into eina lately, but last time i did he started to use evas_list instead of ecore_list, the problem is that i don't think we can choose one of them and then port the rest to that, it isn't only a different way of API, it also results in a different code structure and some things aren't possible with the one implementation, which aren't possible with the other. So i think we have to go with boths, if we don't want to move the release date into the fare future. Using both reduce the porting to the new API to a simple sed script. I don't think, that it is much work to put things together, the code is already here, no matter if we take it from evas, ecore, edata or eina. Some lines of sed, maybe a reindent and then adding it to the Makefile.am and the header to the Edt.h (or how name it). > >> I hope that clarify things >> > > I just don't like edt as a name, but that's really not something > important :-) So as long as we have a plan to merge all data type into > one lib, I will be happy. > I'd prefer eina, as well :). But that would break then turran's code, if we don't take all of its code. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Vincent Torri schrieb: >> >> I think that Hisham wants you to put your code in edata, and not create >> another lib. >> > Unfortunately, it isn't that easy. We have two (or with other counting 3 > or 4) list implementations and two hash implementations. Since their API > is totally different, especially for the lists, we cannot simply choose > one of them and port the rest to that API without an incredibly huge > amount of work. So the only way we can handle it is to have both > implementations parallel in the data lib. But how are we going to name > them? Maybe we name the evas_list edt_nodes or we name the ecore_list > edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the > evas_list. For the hashs the situation is a bit better. After Nathan has > his ecore_hash improvements in. We can make the evas_hash a wrapper > around it. But we still need to think about a name for it, maybe > edt_strhash. Where we can really unify stuff is for ecore_list2 and > evas_object_list, i think we can take there turran's eina_inlist. And > edata has also an edata_array, what are we going to use evas_array or > edata_array, or do we also need both? Besides that I wouldn't put > ecore_tree into the new lib before it is fixed, it is currently in an > unusable state. We also have some inthash and we need hash indexed by two int for the font subsytem. And you forgot the simple hash and list implementation of eet :-) Yes, the situation is a bit complex... > As you can see there are many open questions, that needs to be answered > first. That's why raster had the idea to first put the string pool into > the new lib, because - as mentioned before - the API is the same. Of > course we still need to discuss what is going into that lib and how. If > people prefer to discuss it yet and do the whole stuff later at once, we > can do this as well, but just taking edata doesn't work. But why didn't we just put eina inside the libs cvs directory (svn checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And start hacking from here. We can then slowly switch evas , ecore and eet to the data type eina provide or the one we add to eina. It should be easier to start from something with code and hack than agree on what we should put in. But if you are going to do the work, I will agree and help on this project as it's something we need to do. > I hope that clarify things I just don't like edt as a name, but that's really not something important :-) So as long as we have a plan to merge all data type into one lib, I will be happy. -- Cedric BAIL - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Vincent Torri schrieb: > > I think that Hisham wants you to put your code in edata, and not create > another lib. > > Unfortunately, it isn't that easy. We have two (or with other counting 3 or 4) list implementations and two hash implementations. Since their API is totally different, especially for the lists, we cannot simply choose one of them and port the rest to that API without an incredibly huge amount of work. So the only way we can handle it is to have both implementations parallel in the data lib. But how are we going to name them? Maybe we name the evas_list edt_nodes or we name the ecore_list edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the evas_list. For the hashs the situation is a bit better. After Nathan has his ecore_hash improvements in. We can make the evas_hash a wrapper around it. But we still need to think about a name for it, maybe edt_strhash. Where we can really unify stuff is for ecore_list2 and evas_object_list, i think we can take there turran's eina_inlist. And edata has also an edata_array, what are we going to use evas_array or edata_array, or do we also need both? Besides that I wouldn't put ecore_tree into the new lib before it is fixed, it is currently in an unusable state. As you can see there are many open questions, that needs to be answered first. That's why raster had the idea to first put the string pool into the new lib, because - as mentioned before - the API is the same. Of course we still need to discuss what is going into that lib and how. If people prefer to discuss it yet and do the whole stuff later at once, we can do this as well, but just taking edata doesn't work. I hope that clarify things Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Tue, 8 Jul 2008, Peter Wehrfritz wrote: > Hisham Mardam Bey schrieb: >> On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: >> >>> I've put now the evas stringshare code into a standalone lib. I know >>> that Nathan is working on improving ecore_hash, so that ecore_string >>> becomes faster. We can still change the code later, since the API and >>> ABI remains the same. I called that lib "edt" for "enlighten data >>> types". >>> >> >> At this point, I'm going to point you to Jorge's edata. Stuff should >> go in there if anything. >> >> > I actually took edata's infrastructure as a starting point. And what is > that special with edata? It is more or less the same code like the ecore > code, only the formating was changed and the headers are split. There is > even still the ecore_list2 in, although it isn't used anywhere. Only > thing that is new to it, is the array implementation. Besides that it > doesn't contain what we are talking about, a string pool. I think that Hisham wants you to put your code in edata, and not create another lib. Vincent - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Hisham Mardam Bey schrieb: > On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> I've put now the evas stringshare code into a standalone lib. I know >> that Nathan is working on improving ecore_hash, so that ecore_string >> becomes faster. We can still change the code later, since the API and >> ABI remains the same. I called that lib "edt" for "enlighten data >> types". >> > > At this point, I'm going to point you to Jorge's edata. Stuff should > go in there if anything. > > I actually took edata's infrastructure as a starting point. And what is that special with edata? It is more or less the same code like the ecore code, only the formating was changed and the headers are split. There is even still the ecore_list2 in, although it isn't used anywhere. Only thing that is new to it, is the array implementation. Besides that it doesn't contain what we are talking about, a string pool. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > I've put now the evas stringshare code into a standalone lib. I know > that Nathan is working on improving ecore_hash, so that ecore_string > becomes faster. We can still change the code later, since the API and > ABI remains the same. I called that lib "edt" for "enlighten data > types". At this point, I'm going to point you to Jorge's edata. Stuff should go in there if anything. -- Hisham Mardam Bey http://hisham.cc/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Peter Wehrfritz schrieb: > Yesterday we had a discussion on irc, if we should put abstract data > types of ecore and of evas into a single standalone lib. The whole > discussion came up because of the two implementations of the shared > strings. And in fact if we really want to share strings efficient, we > have to share them over the borders of the different libraries. > > Raster's idea was to first put the shared string stuff in this new > library because both implementation have the same api (of course the > names are different) and the same functionality. Remains the question > which implementation we use. > I've put now the evas stringshare code into a standalone lib. I know that Nathan is working on improving ecore_hash, so that ecore_string becomes faster. We can still change the code later, since the API and ABI remains the same. I called that lib "edt" for "enlighten data types". If you prefer another name I can change it easily. It isn't much work at that point. I also can change the function names they are now: edt_stringshare_init edt_stringshare_shutdown edt_stringshare_add edt_stringshare_del If you like it, i can commit it. Next step would be to make ecore and evas depend on edt. And make their functions to be only wrappers around edt's one. And then we can replace step by step the names in the libs and apps. You can find the lib here: www.mowem.de/e/edt.tar.gz Kind Regards Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Fri, 09 May 2008 19:21:43 +0200 Peter Wehrfritz <[EMAIL PROTECTED]> babbled: > The (only) one alloc is most probably the reason why has better results > for adds and removes then the ecore counter-parts. It's probably > possible somehow to improve the situation for ecore_hash, but it'd make > the code more of ecore_hash to alloc only one piece of memory per item. > I think it isn't worth it, because i don't see a general usage for such > a feature. yeah. that's where stringshare just implemented its own hash entirely - this way it gets around it. the ecore solution is nicer in that it recycles existing hash ans such subsystems - the stringshare one is less nice but simply faster. > > now... more interestingly - i now started looking at the test. it is very > > artificial. > > Yes, i know. I start to read the two implementations and saw the > difference. And i wondered if how they affect the performance. How much > is the overhead of the two allocations? Where will evas start to suck, > because of the static bucket count. So i've written the test case to get > a feeling for it. I know it is artificial, but I think it is still > interesting, even if it doesn't represent a normal usage. yup. it was so interesting i spent a lot of effort looking into this! :) i increased the default bucket size and so have basically put stringshare where its optimal for the usage pattern in e17 at any rate, > Imho, the key point is how many strings are added to the hash. For small > apps that only share a dozen of strings, the hash is bigger then needed, > although the extra 4k are probably a overhead most people can live with. yeah. its a small enough base overhead (you only pay once in the app) where i think its not worth quibbling over. > And i don't know if there are apps where the number of strings ever > exceed 10,000, assumedly not. I haven't tested yet, how many shared > strings ewl has. I think as long noone reports that he is using > evas_stringshare or ecore_string with much more then 10,000 strings, we > can take the evas code for the new lib. and we can always increase the base hash size, or add in core to dynamically resize and re-hash when/if needed. > BTW, we will need evas_stringshare_init()/_shutdown() functions, so > nobody has to have the 4k occupied memory if he doesn't use stringshare > and _shutdown() can clean up the memory if there are still unreleased > strings. For instance ewl loose some references intentionally, because > they are quit often used. I'll write them, if the evas implementation is > chosen. agreed. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Carsten Haitzler (The Rasterman) schrieb:
> after. i've run the tests myself now.
>
> i'll add some stats. e17 maintains about 3000-4000 unique strings in
> evas_stringshare. in my tests. i also checked on number of adds, dels and
> lookups in evas_stringshare usage. about 6.48% of calls are for adds of a
> unique string. 5.12% are for deletes of a string. 88.41% are accesses (an add
> or a del of an existing string where the operation does not free or allocate
> any memory but just refcounts up or down).
>
> now based on this, the existing stringshare vs. string_instance means, that if
> you account for the relative usage of add, del and access paths,
> string_instance gets overall faster once you have about 3200 or so strings. so
> e17 is about at the cusp point. it's also one of the heavier users i imagine.
>
> i simply changed hash bucket size to be 1024 items instead of 256 and that
> makes the crossover point at about 7200 strings items - well beyond normal
> usage of e17 anyway. adds and delets are still significantly faster (string
> instance takes 1.8 and 1.4 times the time respectively compared to
> stringshare)
> even at 10,000 strings. with the 1024 buckets for stringshare of course. but
> string_instance takes 0.8 times the time for lookups.
>
> overall it's a close race. i'll try improve stringshare a little and see what
> i
> get, but beyond making it have dynamic bucket sizes (like ecore_hash) it isn't
> likely to go far. a dynamic bucket size will mean it will scale very high
> (question: do we need it to go that high?) but the idea of having to re-do the
> bucket array at certain points is a little uncomfortable (so u go from 3000 to
> 3001 and the system has to spend extra cycles re-packing all hash items in a
> new
> bucket set thats bigger). yes - this is nicer in terms of base mem usage of
> course. so the thing here is to figure out how to get the best thing we can
> for
> the least cost. i do know stringshare has a 1 alloc per unique string
> overhead.
> thats about as small as it gets (also either 8 or 12 bytes (32 or 64bit) per
> unique string for refcount and pointer).
>
The (only) one alloc is most probably the reason why has better results
for adds and removes then the ecore counter-parts. It's probably
possible somehow to improve the situation for ecore_hash, but it'd make
the code more of ecore_hash to alloc only one piece of memory per item.
I think it isn't worth it, because i don't see a general usage for such
a feature.
> now... more interestingly - i now started looking at the test. it is very
> artificial.
Yes, i know. I start to read the two implementations and saw the
difference. And i wondered if how they affect the performance. How much
is the overhead of the two allocations? Where will evas start to suck,
because of the static bucket count. So i've written the test case to get
a feeling for it. I know it is artificial, but I think it is still
interesting, even if it doesn't represent a normal usage.
> at most 2 copies of a string, so n repeated adds, and all short
> strings. not very representative of common usage. in common usage i have
> seen some strings with refcounts of > 200. in fact the del wont work with
> stringshare. on del u need to supply the actual string pointer - not the
> snprintf'd buffer. so nothing gets found and deleted. ie its meant to work
> with:
>
> char *s;
>
> s = evas_stringshare_add("string");
> ...
> evas_stringshare_del(s);
>
> ie - the same return from stringshare.
> evas_stringshare_del("string") will not work.
>
> ... so as such you need a test that is more representative of actual usage.
>
> so that's just what i did. i literally logged all stringshare add's, dels etc.
> in such a way it'd produce "correct code" from a session of e17 i fiddled with
> for about 5 minutes doing stuff. you'll forgive me for not including the code
> as the .c file generated is 11m (239,000 lines of c) that i included into the
> compare.c infra to test both ecore and evas code and just time it doing
> exactly
> what e does. i also included "nops" where functions are called, but do nothing
> so we can remove the simple test harness and function call overhead and
> compare
> just core. as it was a little too fast i make it run 1000 loops of what e
> actually does one after the other (yes it'll be bad as it doesn't start with a
> clean slate but better than nothing). result for 1000 iterations one after the
> other:
>
> evas: 20.691495
> ecore: 30.510302
> nops: 3.444793
>
> real factor: 1.57
>
> so really 20.69 - 3.44 vs 30.51 - 3.44 - i.e 17.25 vs 27.07 (evas being the
> lower). yes - this means a lot of things will get high refcounts as things get
> re-added a lot and then not removed, so the raw results of only 1 iteration:
>
> evas: 0.031672
> ecore: 0.045482
> nops: 0.004831
>
> real factor: 1.51
>
> not as accurate as the times are so small, but the same order of magnitude as
> above.
>
> so as such... if we are doing bench
Re: [E-devel] Shared Strings
On Wed, May 7, 2008 at 2:20 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Yesterday we had a discussion on irc, if we should put abstract data > types of ecore and of evas into a single standalone lib. The whole > discussion came up because of the two implementations of the shared > strings. And in fact if we really want to share strings efficient, we > have to share them over the borders of the different libraries. > > Raster's idea was to first put the shared string stuff in this new > library because both implementation have the same api (of course the > names are different) and the same functionality. Remains the question > which implementation we use. > > And for something completely non-technical now. I went over this discussion's backlog over irc and talked to Jorge (turran) as well. Whatever ends up happening, I want to point you to Jorge's work on this matter (a general shared data library that should be used by the EFL as opposed to maintaining per library implementations). Currently, there are two, one in the EFL's CVS repository, and one in the EFL-Research SVN repository on Google code. I want to remind everyone that this effort has already been started, and the idea has been indeed put forth by Jorge, and if anyone wants to work on something like this they should in fact continue, build upon, and help Jorge with developing this common library. This library has been there floating in CVS for (over?) a year now, so pick it up and keep the ball rolling. -- Hisham Mardam Bey http://hisham.cc/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Wed, 7 May 2008 20:55:40 -0500 "Nathan Ingersoll" <[EMAIL PROTECTED]>
babbled:
after. i've run the tests myself now.
i'll add some stats. e17 maintains about 3000-4000 unique strings in
evas_stringshare. in my tests. i also checked on number of adds, dels and
lookups in evas_stringshare usage. about 6.48% of calls are for adds of a
unique string. 5.12% are for deletes of a string. 88.41% are accesses (an add
or a del of an existing string where the operation does not free or allocate
any memory but just refcounts up or down).
now based on this, the existing stringshare vs. string_instance means, that if
you account for the relative usage of add, del and access paths,
string_instance gets overall faster once you have about 3200 or so strings. so
e17 is about at the cusp point. it's also one of the heavier users i imagine.
i simply changed hash bucket size to be 1024 items instead of 256 and that
makes the crossover point at about 7200 strings items - well beyond normal
usage of e17 anyway. adds and delets are still significantly faster (string
instance takes 1.8 and 1.4 times the time respectively compared to stringshare)
even at 10,000 strings. with the 1024 buckets for stringshare of course. but
string_instance takes 0.8 times the time for lookups.
overall it's a close race. i'll try improve stringshare a little and see what i
get, but beyond making it have dynamic bucket sizes (like ecore_hash) it isn't
likely to go far. a dynamic bucket size will mean it will scale very high
(question: do we need it to go that high?) but the idea of having to re-do the
bucket array at certain points is a little uncomfortable (so u go from 3000 to
3001 and the system has to spend extra cycles re-packing all hash items in a new
bucket set thats bigger). yes - this is nicer in terms of base mem usage of
course. so the thing here is to figure out how to get the best thing we can for
the least cost. i do know stringshare has a 1 alloc per unique string overhead.
thats about as small as it gets (also either 8 or 12 bytes (32 or 64bit) per
unique string for refcount and pointer).
now... more interestingly - i now started looking at the test. it is very
artificial. at most 2 copies of a string, so n repeated adds, and all short
strings. not very representative of common usage. in common usage i have
seen some strings with refcounts of > 200. in fact the del wont work with
stringshare. on del u need to supply the actual string pointer - not the
snprintf'd buffer. so nothing gets found and deleted. ie its meant to work with:
char *s;
s = evas_stringshare_add("string");
...
evas_stringshare_del(s);
ie - the same return from stringshare.
evas_stringshare_del("string") will not work.
... so as such you need a test that is more representative of actual usage.
so that's just what i did. i literally logged all stringshare add's, dels etc.
in such a way it'd produce "correct code" from a session of e17 i fiddled with
for about 5 minutes doing stuff. you'll forgive me for not including the code
as the .c file generated is 11m (239,000 lines of c) that i included into the
compare.c infra to test both ecore and evas code and just time it doing exactly
what e does. i also included "nops" where functions are called, but do nothing
so we can remove the simple test harness and function call overhead and compare
just core. as it was a little too fast i make it run 1000 loops of what e
actually does one after the other (yes it'll be bad as it doesn't start with a
clean slate but better than nothing). result for 1000 iterations one after the
other:
evas: 20.691495
ecore: 30.510302
nops: 3.444793
real factor: 1.57
so really 20.69 - 3.44 vs 30.51 - 3.44 - i.e 17.25 vs 27.07 (evas being the
lower). yes - this means a lot of things will get high refcounts as things get
re-added a lot and then not removed, so the raw results of only 1 iteration:
evas: 0.031672
ecore: 0.045482
nops: 0.004831
real factor: 1.51
not as accurate as the times are so small, but the same order of magnitude as
above.
so as such... if we are doing benchmarks to know which implementation to use to
find the one with best results - at least for the case of e17, evas is the
winner here. of course if you think e17's use case is pretty atypical and you
need another one, we should continue to check.
comments. ?
> Were these numbers from ecore before or after cedric's changes this morning?
>
> On Wed, May 7, 2008 at 1:20 PM, Peter Wehrfritz <[EMAIL PROTECTED]>
> wrote:
> > Yesterday we had a discussion on irc, if we should put abstract data
> > types of ecore and of evas into a single standalone lib. The whole
> > discussion came up because of the two implementations of the shared
> > strings. And in fact if we really want to share strings efficient, we
> > have to share them over the borders of the different libraries.
> >
> > Raster's idea was to first put the shared string stuff in this new
> > library because both implementation have the same api (of c
Re: [E-devel] Shared Strings
Nathan Ingersoll schrieb: > Were these numbers from ecore before or after cedric's changes this morning? > I updated ecore_data just before. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Were these numbers from ecore before or after cedric's changes this morning? On Wed, May 7, 2008 at 1:20 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Yesterday we had a discussion on irc, if we should put abstract data > types of ecore and of evas into a single standalone lib. The whole > discussion came up because of the two implementations of the shared > strings. And in fact if we really want to share strings efficient, we > have to share them over the borders of the different libraries. > > Raster's idea was to first put the shared string stuff in this new > library because both implementation have the same api (of course the > names are different) and the same functionality. Remains the question > which implementation we use. > > > Therefor I've written a small test application, to measure the time it > takes to create new strings, access new strings and to delete them. > > You can find the program here: > mowem.de/ecore/compare.c > > And here a here the plot of the result > mowem.de/ecore/result_direct.ps > > In short words, since evas uses a static bucket count it has a very good > performance for few strings, for many ecore has a good access time, but > still pays the price for the reordering of the increased or decreased > bucket count. > > Peter > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
