Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx009.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j2UFHNJc009451
        for <joris.at.lebbeke@skynet.be>; Wed, 30 Mar 2005 17:17:24 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 2EA64194126C; Wed, 30 Mar 2005 10:17:05 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from scooby.simplesystems.org (scooby.simplesystems.org
	[65.66.246.67])
	by xserve.flids.com (Postfix) with ESMTP id 43F401941249
	for <tiff@remotesensing.org>; Wed, 30 Mar 2005 10:17:02 -0500 (EST)
Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74])
	by scooby.simplesystems.org (8.12.10+Sun/8.12.10) with ESMTP id
	j2UFH1Ai024238; Wed, 30 Mar 2005 09:17:01 -0600 (CST)
Date: Wed, 30 Mar 2005 09:17:01 -0600 (CST)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@blade.simplesystems.org
To: Joris <joris.at.lebbeke@skynet.be>
Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
In-Reply-To: <001801c534fd$b30fe220$5b99f651@dfgrrxsknr4e>
Message-ID: <Pine.SOC.4.60.0503300909010.8945@blade.simplesystems.org>
References: <20050330001802.GB4298@hank.shelbyville.oz><Pine.SOC.4.60.0503292118290.8945@blade.simplesystems.org>
	<20050330055510.GA10045@hank.shelbyville.oz>
	<001801c534fd$b30fe220$5b99f651@dfgrrxsknr4e>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 000000000023ceae.00000039
X-MSP-STORE: Wed, 30 Mar 2005 17:17:37 +0200
Status:   

On Wed, 30 Mar 2005, Joris wrote:

> If I'm interpreting your goals correctly, I'm afraid you might be confusing the
> issue with all this talk about memory maps and other implementation issues. I've
> personally always considered memory mapping TIFFs a bad idea. There's no telling
> what size files you might need to handle, especially with the new BigTIFF
> format. You could need to eat 8 gig of address space on a machine that is
> theoretically limited to 2 gig for memory maps, and shares this 2 gig with other
> applications, like I think is the case on common windows systems. Moreover,
> there seems very little benefit to abusing address space like this, as opposed
> to good ol' plain file IO, especially given the fact that you'll need to aling
> and byteswap in seperately allocated memory blocks anyhow.

It is not necessary to map the entire file at once.  A relatively 
small "peephole" of memory mapping (e.g. 256K) may be used to access 
large files.  There is not much overhead associated with the map/unmap 
process. The key thing is if the memory mapping API is able to support 
large files.  For POSIX mmap(), this is determined by the size of the 
off_t type.  For Large File System (LFS) builds, or POSIX operating 
systems which support large files by default, off_t has at least 63 
usable bits.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
