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/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
