On Sat, 20 Jun 2009 12:50:30 +0200 Cedric BAIL <[email protected]> said:
> On Sat, Jun 20, 2009 at 11:57 AM, Carsten Haitzler<[email protected]> > wrote: > > On Sat, 20 Jun 2009 04:42:13 -0300 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> > yes. you need to add it then del it when you exit or dont need it any > >> > more etx. so you actually made the code more complicated AND you now > >> > assume that the string is stringshare. this is relatively evil to do > >> > between abi's. within a single app/lib it's evil, but ok, but modules > >> > and e are like 2 sides of a library api. these kind of assumptions > >> > pretty much exposing internal functionality, is pretty evil. and for > >> > more complicated code, exposing internals where not really needed, all > >> > for the sake of a speed gain i challenge you to actually measure ever in > >> > real life :) just need to be careful where to focus efforts. don't focus > >> > them where you make the least or no gains. :) > >> > >> okay, okay... here it does not gain much, but I want to change efreet > >> one day to use more stringshared arguments. Looking at it (efreet) I > >> can see huge speedups, specially in querying stuff that we have on > >> efm/ui. But again, ok, in this case nothing much to win, but > >> enums/ints are better anyway > > > > efreet is indeed another story. it's TONNES and TONNES of strings. it's a > > huge memory blob there. in fact what efreet needs is a way to take its > > in-memory database, serialse to a file on disk, then mmap() it. and mmap() > > it when first needed, then unamp() it after a period of non-use. this dumps > > a large chunk of > > Is it really usefull to unmap ? can't we trust the kernel to drop it > when under presure ? unmapping should help give a hint... it also looks better in top/ps :) > > string data to a file on disk. additionally, it allows for a cache, so on > > startup - just mmap the file, then some time after startup, run a scan in > > the background and re-build the cache (to make sure it's up to date), > > monitor the directories and on changes rebuild the cache and mmap again. > > the mmaped file should basically have a string dict - like eet, and then > > everything is numeric data structs (ints, booleans) and... string index > > numbers within the file (and there is and index -> file offset table > > somewhere). or it probably is almost as good just storing the offsets > > directly. > > > > so > > > > 1. you get caching and fast startup even on cold boot > > 2. get reduced memory footprint (map and unmap the file as needed) > > > > imho stringshare here isn't what is wanted as the strings are tired > > directly to the data and the data is on disk already. > > Sounds like we directly use eet for that. The dictionnary is mmaped > and it will directly describe the structure of data needed by efreet. > It should be easy to modify part of this structure, save it and reload > it without trouble. Did I miss something ? well i was hopinh to have the actual data mapped to - ie every .desktop file node (That has all the entries - the key/value pair stuff) as well. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
