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