Fully activate the sliding window pack access.
authorShawn O. Pearce <spearce@spearce.org>
Sat, 23 Dec 2006 07:34:28 +0000 (02:34 -0500)
committerJunio C Hamano <junkio@cox.net>
Fri, 29 Dec 2006 19:36:45 +0000 (11:36 -0800)
commit60bb8b1453e2f93d13e7bb44e8e46c085d2dd752
tree3203b1cd4a7479e0175a4c65462ea714ccdabd9b
parent54044bf825d311751e30552248be1e0cac99a5a3
Fully activate the sliding window pack access.

This finally turns on the sliding window behavior for packfile data
access by mapping limited size windows and chaining them under the
packed_git->windows list.

We consider a given byte offset to be within the window only if there
would be at least 20 bytes (one hash worth of data) accessible after
the requested offset.  This range selection relates to the contract
that use_pack() makes with its callers, allowing them to access
one hash or one object header without needing to call use_pack()
for every byte of data obtained.

In the worst case scenario we will map the same page of data twice
into memory: once at the end of one window and once again at the
start of the next window.  This duplicate page mapping will happen
only when an object header or a delta base reference is spanned
over the end of a window and is always limited to just one page of
duplication, as no sane operating system will ever have a page size
smaller than a hash.

I am assuming that the possible wasted page of virtual address
space is going to perform faster than the alternatives, which
would be to copy the object header or ref delta into a temporary
buffer prior to parsing, or to check the window range on every byte
during header parsing.  We may decide to revisit this decision in
the future since this is just a gut instinct decision and has not
actually been proven out by experimental testing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/config.txt
cache.h
config.c
environment.c
sha1_file.c