On Thu, 10 Jan 2008 08:53:25 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled:
> On Jan 10, 2008 7:53 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > > > > > In the current eet file format, string are inside the directory > > structure, so they don't have a fixed size and it's usefull during > > reading to know the size of all directory entries (It's not the direct > > result of some math, but it need the reading of all directory). With > > my proposal, I don't think we will need this information neither the > > size of all stored string. > > There are no other variable size types stored in the directory structure? not the dir struct - no. the only variably things are: strings (eet dir entry names). we can put these into a single chunk near the start of the file as cedric suggests. then they should pack together into 1,2 or so pages of memory. as they are all unique we can't do much to share them :) the # of directory entries. each one per the changes cedric proposes would become fixed size itself. so technically it would be very easy/fast to decode. if we make sure the table is 32bit aligned in the file we can avoid the EXTRACT_INT stuff to handle aligning them and just read (and byteswap if needed) into memory. this chunk of info should be smaller than the strings so it should gain us something. -- ------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
