Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e/doc
Modified Files:
cache.txt
Log Message:
commentsies!
===================================================================
RCS file: /cvs/e/e17/apps/e/doc/cache.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -3 -r1.4 -r1.5
--- cache.txt 15 Sep 2006 21:41:54 -0000 1.4
+++ cache.txt 19 Sep 2006 13:33:23 -0000 1.5
@@ -339,3 +339,62 @@
thumbnailing, but may need more speedups for its globbing.
Later we shall see if an on disk copy is needed.
+
+------------------------------------------------------------------------------
+comments on cache doc:
+
+ 1. ignore caching of image data - evas already does that. just provide
+ file paths and "keys" if inside .edj/eap/eet files. don't duplicate
+ image data or do anything "smart" as it will invariably end up less
+ smart that the existing evas cache :) so don't worry about icons and
+ their pixels - just the file paths/keys
+ 2. instead of "in memory" let's try a new idea. lets put it in a flat
+ mmap'ed file (not eet). let's not make it architecture dependant
+ (write any integers in a fixed byte order) and make it all offset
+ based. fill the file with strings and indexes and fast search indexes
+ etc. 1 big flat file for the whole cache.. the eap structs themselves
+ are "in memory" and allocated but all strings and "content" are pointed
+ to this mmaped file - map and unmap this file whenever needed (need to
+ add calls that implicitly map it when you want to access eap struct
+ contents and then unmap when done - refcount) and on map check the
+ header of the file for some "modification count) and keep the last mod
+ count value - if they don't match re-evaluate all internal tabels in
+ the map file. re-evaluate all pointers in eap structs. always try and
+ map the file to the same mem address (remember it and try map TO that
+ addr so you don't need to do address fixups). if you can't map to there
+ map to unspecified address (let mmap choose) and now keep trying to
+ map to this addr from now on. if the addr changes or the mmap file
+ changes all eap files need a fixup of their str pointers done.
+ so now you have a e_app_use() and e_app_unuse() thatg basically makes
+ sure the apps map file is mappeed after a use and unmapped after an
+ unuse (when refcount goes to 0 for the maps file - maybe with a
+ timeout to avoid map thrashing).
+ the advantage of all this is most of the time e is not accessing eapp
+ data - it just has references TO them so during this time no memory
+ is consumed by the data and no kernel mappings. we should bring mem
+ use down to a tiny fraction.
+ this is a quick braindump... so it may need more discussion. nb - this
+ is just a bug flat dump for all ".desktop files" - hash it for fast
+ lookup - have fast search hash indexes for lookup by exe, name, class
+ etc. other cache files for menu structures etc. would implicitly
+ reference data in this big fat cache.
+ 3. on any change of .desktop files on the system or by users - rewrite the
+ whole cache and re-fix pointers etc. - this shouldn't happen often.
+ 4. same mmap setup for lookups of icon name in .desktop -> fully resolved
+ path based on icon themes and inheritance. if the themes change then
+ re-evaluate this cache.
+ 5. .order files and menu structs can just live in the same cache.
+ 6. all eaps can be quickyl created at startup from an all apps cache that
+ referenced the desktop content cache file as above. putting it into
+ an idel taks means on addition of new eaps all window icons need
+ re-evaluation as to all eap instances in ibar etc. etc. - makes life
+ more complex (for now). maybe simpler on that front and better cache
+ will work well here.
+ 7. eap instances are created as you lanich apps - no need to cache or
+ worry about these - the search by exe, win name/class etc. are what
+ we need to worry about :)
+ 8. the above should mean no need to fill in eaps in idlers - map the
+ "big fat desktop cache" that contains everything - icon paths, labels
+ exe strings etc. when needed - fox up all pointers in eapp structs
+ if the contents or base address ever change - unmap when refcount
+ goes to 0 (with a timeout to avoid thrashing).
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-cvs mailing list
enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
