Re: [Boost-users] boost::interprocess shared memory performance

Subject: Re: [Boost-users] boost::interprocess shared memory performance
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-12-28 07:02:22

Andy Wiese wrote:
> Does managed_shared_memory really need to call msync?

I don't know. Maybe even managed_mapped_file shouldn't call flush() in 
the destructor, because the OS should handle the changes made to the 
memory segment, perhaps maintaining data in memory. The question is 
maybe if closing a file should call fflush() and interprocess should do 
the same.

Anyway, it is possible that unmap provokes implicitly a msync. Can you 
try to comment out the call to flush() in mapped_region's destructor and 
  measure it again?

And just a question, if you bottleneck is msync, this means that you are 
creating and destroying a lot of managed_shared_memory / 
managed_mapped_file instances? That does not seem very 
performance-friendly, since you will be mapping and unmapping pages, 
which is not a lightweight operation.

> I'm writing a little cgi driven database utility that queries data 
> stored in a filesystem directory using a simple query language. I would 
> like to keep indexes of the data to speed query resolution. The utility 
> is old-school cgi, so all its resources (such as indexes) have to be 
> instantiated into memory each time the cgi process is started. I could 
> write indexes to files, but then I incur a de/serialization overhead 
> that is expensive. My intention was to keep the indexes as ready-to-use 
> interprocess::maps in shared memory, to be used by all invocations of 
> the cgi. It works, but the performance of the shared memory is poor 
> enough that I'm not getting much increase over just doing a brute force 
> search through the datafiles.

Ok, try to comment out flush() call and tell me if the difference is 
appreciable.

Regards,

Ion