Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one provided in file_mapping
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-08-20 21:55:41
#9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one
provided in file_mapping
-------------------------+-------------------------------------------------
Reporter: | Owner: igaztanaga
michal.fronczyk@⦠| Status: new
Type: Bugs | Component: interprocess
Milestone: To Be | Severity: Optimization
Determined | Keywords: interprocess mapped_region
Version: Boost | file_mapping
1.54.0 |
Resolution: |
-------------------------+-------------------------------------------------
Comment (by michal.fronczyk@â¦):
Thanks for such a quick response. I think the problem is not about the
time needed to create file mapping, but about the lack of ability to reuse
already fetched pages of the file in different mapped regions. The
performance problem we observed occurred in a multithreaded program. Using
a profiler we discovered that the problem lies in the code where many
threads were creating read-only mapped_regions of the same file using a
shared instance of the file_mapping class. Different threads mapped
different regions of the file, but there was a very high probability that
a thread will shortly need the data region mapped previously by one of the
other threads. I'm assuming that the destructor of the mapped_region class
releases the mapping, so all the pages fetched during using that region
are released when the region is destroyed and need to be fetched again
from the disk when another region maps the same part of the file. Fetching
the same parts of the file many times hurts the performance in our case.
We changed the code to create one shared read-only mapped_region that maps
the whole file and we use pointer arithmetic to read different parts of
the file in different threads. The performance gain we observed was
significant, but I don't have the numbers now. However, this solution
isn't ideal because we can't do that in the 32bit version of the app since
the file is big (several GBs). We map the whole file in the 64bit version
only. BTW, do you see any problems with mapping a 20GB file as a whole to
the 64bit address space?
My thinking is that keeping the file_mapping instance and reusing it in
multiple mapped_regions, that map small portions of the file, will allow
us to reuse the fetched file pages in different mapped_regions as needed
and the performance will be more or less the same as in the case of one
shared mapped_region that maps the whole file. Please let me know if I'm
wrong.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/9019#comment:3> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:13 UTC