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 ? > 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 ? -- Cedric BAIL ------------------------------------------------------------------------------ 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
