Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net