I've often wondered if a more sparse representation of modified data that *only* contains the modifications would save memory and also give acceptable lookup performance. Presumably after modification its likely that a commit will follow shortly, so then it might make sense to penalize lookups that happen between modifications and commits. Just a thought.
--JYL > for clarification: > MK saves modified columns of data on the heap. when you commit, it > writes them to the file (via normal i/o or memory mapping, as > appropriate), and then frees that heap space. so if the file is mapped > (as it will be if it is not huge) the total space in use stays about the > same over a commit. the virtual space will likely grow, for the first > commit, as the memory allocator likely keeps the freed heap in the > virual space. > > --- Jacob Levy <[EMAIL PROTECTED]> wrote: >> Bernard >> >> Committing does not free the memory. As I said before, Metakit maps >> the *entire file* into memory. So if the file grows, so does the >> memory mapping requirement. Whether the physical RAM used by the >> program grows or not is a factor influenced by the OS, not by Metakit. >> >> --JYL > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > _____________________________________________ > Metakit mailing list - [EMAIL PROTECTED] > http://www.equi4.com/mailman/listinfo/metakit _____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
