LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
Previous by Thread
Next by Thread
Previous by Date
Next by Date
The TIFF Mailing List Homepage
Archive maintained by AWare Systems
2016.01.29 15:49 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
On Fri, Jan 29, 2016 at 10:48 AM, Aaron Boxer <firstname.lastname@example.org> wrote:
On Fri, Jan 29, 2016 at 9:46 AM, Bob Friesenhahn < email@example.com> wrote:
Thanks. This is exactly the work flow I am interested in: tens of thousands of ~10 MB TIFFs, accessed
>>> sequentially. Only 4 files would be open at a given time. So, even >>> though the files get closed, are you
suggesting I will see swapping in this case?
It would not be true swapping or paging-out (actually, there could be some paging out to swap), but there will be memory pressure since memory mapping behaves as a cache. The file data
is still in memory (by default) after the file has been unmapped and memory pages are re-claimed (existing contents forgotten, and page re-purposed) for new activity based on new
memory pressures, and the time the memory has remained inactive.
The actual behavior is highly OS implementation dependent.
On Unix type systems, the madvise() function can be used to help control behavior of memory-mapped data (e.g. MADV_DONTNEED), but again behavior is highly OS implementation dependent
and the only way to know for sure is to test.
Thanks, Bob. On windows, since there is no madvise function, wouldn't reading a file and memory mapping the file both give the same result: the file gets cached in the OS file cache,
causing memory pressure when the cache gets filled up?
By reading, I mean using the fopen/fread interface, vs memory mapping.