David Bradley wrote: > You'd eliminate the freads, but you still would have to "parse" the > data and allocate language structures to represent the data. If you > don't do that, then you'd sacrafice time on accessing these > structures, since accessing them would be less efficient. The crux of > the problem is that the file can't store pointers.
Even taking this into account you still save because you don't have to allocate memory to read from the into a buffer. Just map the file and you have the pointer - no need for fread'ing at all. > What could be done is to store the data in a file such that it maps > directly to C/C++ structs/classes. And "pointers" are respresented as > offsets to the start of the memory mapped file. You have two choices > at this point, fixup the pointers when you load the file. You take the > hit at startup. Or fix as you go, pay at use. They each have their > disadvantages. Being able to use the component registry directly from disk would be a big win for some embedders. If necessary calculate a few hash-tables to supplement the memory mapped file so you don't have to worry about offsets. This must work out cheaper at least memory wise than slurping the entire registry into memory. > Adam Lock wrote: > >> Win32 and Linux both have APIs for mapping a file into a memory so it >> can be accessed via a pointer just like any other memory. >> >> This sounds like it would be an extremely straightforward way to cut >> down the time taken to load type libraries and the registry into >> memory. Instead of malloc'ing a chunk of memory and fread'ing the >> file into it, we just map the whole file straight in and it's there. >> Bits of the file are paged in just like VM whenever they're accessed. >> >> Does this sound like a good idea? Perhaps it could even be extended >> to other things such as fastload files. > >
