On Jan 5, 2010, at 9:08 AM, Ion Gazta?aga <igaztanaga@gmail.com> wrote:
I think most in-memory databases use T-trees as main containers. I plan to add them as Interprocess containers for late 2010, but of course, that will depend on my free time. With those containers, we could speed up searches and waste less space.
Would the interface remain identical to map? The current 'trans_map' can be revised slightly so that it would be a transactional wrapper for any map implementation, leaving the internals of storage to the implementation. Taking advantage of a T-tree variant would then be very easy to accomplish. One of the biggest challenges I'm seeing with high throughput on map is that operations like insert() and erase() cannot be done to concurrently by multiple threads, and consequently those operations become a bottlneck. I'm doing operations like find() and updates (to different entries) in parallel. A map implementation which internally segmented itself into sections under independent mutexes in order to permit highly concurrent modifications of any kind would be a big help. Anyone know of any such implementations? - Bob