On Sat, 8 Dec 2007, Christoph Bartoschek wrote: >> We can fix Memcheck by falling back to the reference version, but I'd >> like to see if there is a way to get the correct behaviour without >> the extra conditionals. > > I would propose that you use a hashtable for the entries with one of the > already used hashfunctions. You would get the following two benefits: > > - An amortized O(1) access time instead of O(log(n)) for all operations. > > - For some big programs (the ones I run) more than 70% of the memory > consumption of memcheck is for the entries of secVBitTable2. Using a > hashtable (preferably with a memory pool for the entries or a space efficient > memory manager) would save about 16-24 bytes per entry.
I just spoke with Julian. For this release, we're just going to use the slower version that is correct. Any other change is too big at this late stage. After the release, we can look at using a hashtable instead. Christoph, if you are able to try using the hashtable instead and give us some performance numbers and a patch, that would be very helpful. Nick ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
