From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: <git@vger.kernel.org>
Subject: Re: git_checkattr() is inefficient when repeated [Re: [PATCH 00/11] Micro-optimizing lookup_object()]
Date: Mon, 15 Aug 2011 16:19:00 -0700 [thread overview]
Message-ID: <7vliuujmaj.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <201108121759.24884.trast@student.ethz.ch> (Thomas Rast's message of "Fri, 12 Aug 2011 17:59:24 +0200")
Thomas Rast <trast@student.ethz.ch> writes:
> Which would be a 4.5% speedup. Obviously that won't quite be
> attainable since we want the attributes mechanism to work, but we
> still shouldn't have to open 4398 .gitattributes files when there are
> only 8 .gitattributes plus one .git/info/attributes.
True. At runtime, the attribute mechanism wants a stack of per-directory
attributes it can walk up to find the applicable ones maintained for the
directory it currently is looking at, and the elements near the leaf are
popped from the stack to be discarded when the caller goes on to inspect
paths in a different directory (IOW the machinery is optimized for callers
that walk the paths in order, without randomly jumping around).
But at least within a process like pack-objects that are known to be long
lived, we should be able to instead _keep_ the elements that are popped
when we leave directories at deeper levels, and bring them back to the
stack when the caller asks for a path in that directory later, without
going back to the filesystem.
prev parent reply other threads:[~2011-08-15 23:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 17:53 [PATCH 00/11] Micro-optimizing lookup_object() Junio C Hamano
2011-08-11 17:53 ` [PATCH 01/11] object.c: code movement for readability Junio C Hamano
2011-08-11 17:53 ` [PATCH 02/11] object.c: remove duplicated code for object hashing Junio C Hamano
2011-08-11 17:53 ` [PATCH 03/11] pack-objects --count-only Junio C Hamano
2011-08-11 17:53 ` [PATCH 04/11] object: next_size() helper for readability Junio C Hamano
2011-08-11 17:53 ` [PATCH 05/11] object hash: we know the table size is a power of two Junio C Hamano
2011-08-11 17:53 ` [PATCH 06/11] object: growing the hash-table more aggressively does not help much Junio C Hamano
2011-08-11 17:53 ` [PATCH 07/11] object: try naive cuckoo hashing Junio C Hamano
2011-08-11 17:53 ` [PATCH 08/11] object: try 5-way cuckoo -- use all 20-bytes of SHA-1 Junio C Hamano
2011-08-11 17:53 ` [PATCH 09/11] object: try 4-way cuckoo Junio C Hamano
2011-08-11 17:53 ` [PATCH 10/11] object: try 3-way cuckoo Junio C Hamano
2011-08-11 17:53 ` [PATCH 11/11] object: try 2-way cuckoo again Junio C Hamano
2011-08-11 23:33 ` [FFT/PATCH 12/11] object.c: make object hash implementation more opaque Junio C Hamano
2011-08-12 15:59 ` git_checkattr() is inefficient when repeated [Re: [PATCH 00/11] Micro-optimizing lookup_object()] Thomas Rast
2011-08-15 23:19 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vliuujmaj.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).