AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2016

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2016.01.25 18:25 "OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:05 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:17 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.25 19:18 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 20:21 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 20:45 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 23:27 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.26 09:12 "Re: OpenMP enabled libtiff", by <jcupitt@gmail.com>
2016.01.26 13:45 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 14:46 "Re: OpenMP enabled libtiff", by Olivier Paquet
2016.01.26 16:01 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 17:10 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 19:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 19:29 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 20:36 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.27 18:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.27 19:55 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 13:28 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 14:46 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 15:48 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 15:49 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 18:12 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 09:36 "Re: OpenMP enabled libtiff", by Mat Maher
2016.01.26 09:52 "Re: OpenMP enabled libtiff", by Even Rouault
2016.01.26 14:22 "Re: OpenMP enabled libtiff", by Fred Rothganger
2016.01.27 18:51 "Re: OpenMP enabled libtiff", by Larry Gritz

2016.01.27 19:55 "Re: OpenMP enabled libtiff", by Bob Friesenhahn

On Wed, 27 Jan 2016, Aaron Boxer wrote:
> 
> Thanks, Bob. So, are you saying that as TIFF is currently designed, memory
> mapping is beneficial  ? Because of the random access ?
> This was my experience on windows : turning off memory mapping when using
> libtiff degraded performance.

The memory mapping does eliminate system call and access time 
overheads associated with seeking, as long as data in the same MMU 
page (e.g. 4k block) has been touched before.  This is why libtiff 
memory maps for reads by default under Unix.

Before making comprehensive decisions about degraded performance, try 
the use case where a large sequence of files is accessed in order 
(each accessed once for each traversal) and the total amount of file 
data is much larger than the amount of memory in your system.  In that 
case, do you see the same win or do you now see a penalty which looks 
very much like what happens when the system runs out of memory 
("swapping")?

> My other question is : why is unix and windows treated differently 
> in tifflib?  mmap call allows sharing of mapping between different 
> file handles, while on windows this is turned off. I think it would 
> be nice to have on windows.

I don't know why this is.  Memory mapping works fine for reads under 
Windows although the maximum contigious map size is likely to be 
smaller than on Unix type systems.  It does not work so well for 
writes due to stupidity and missing certain useful POSIX functions 
like ftruncate().  Many functions which might otherwise be useful do 
not support large files or behave in much stupider ways (e.g. actually 
write zeros to the filesystem rather than create a hole) than on Unix 
type systems.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/