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