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
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.

> >> Actually, after discussing this Sergey just wisely remembered that we
> >> should use simple ENUM/integers and that gets even more simpler. Given
> >> the number of things this could grow, I would even say that integers
> >> should be powers of 2 and use a mask of accepted types, then no need
> >> to do functions and all, just set your mask and be happy.
> >>
> >>
> >> >> Last but not least, since we have common stuff here, provide the
> >> >> following functions by default:
> >> >>  - PREFIX_only_shelf_is_site()
> >> >>  - PREFIX_only_desktop_is_site()
> >> >>  - PREFIX_only_efm_toolbar_is_site()
> >> >>  - PREFIX_not_efm_toolbar_is_site()
> >> >>
> >> >> they should be used by modules to avoid duplication, and you can have
> >> >> them to use the globals with the stringshared version of names you
> >> >> created before (at init time).
> >> >
> >> > what are these funcs. it's not clearly explained.
> >>
> >> they would be common functions most modules would set instead of
> >> creating their own replicas, like defining this in every module:
> >>
> >> BLA_is_site(const char *query)
> >> {
> >>     return (!query || strcmp(query, "desktop") == 0);
> >> }
> >>
> >> one would set: is_site = PREFIX_only_desktop_is_site. (PREFIX = some
> >> prefix we choose for this, like e_gadcon_client).
> >
> > but what is PREFIX? gadcon_helper_only_desktop_is_site ? or the module name?
> > what? :)
> 
> e_gadcon_client_class_ or like it. It would be available in E, so not
> using module name.

ok. good. :)

-- 
------------- 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

Reply via email to