All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Harlan <pgit@pcharlan.com>
To: Kjetil Barvik <barvik@broadpark.no>
Cc: git@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH/RFC v3 1/2] Optimised, faster, more effective symlink/directory detection
Date: Fri, 09 Jan 2009 02:20:18 -0800	[thread overview]
Message-ID: <496724E2.6010907@pcharlan.com> (raw)
In-Reply-To: <1231334689-17135-2-git-send-email-barvik@broadpark.no>

Here are some suggestions for the commit message.

Kjetil Barvik wrote:
> Changes includes the following:
> 
> - The cache functionality is more effective.  Previously when A/B/C/D
>   was in the cache and A/B/C/E/file.c was called for, there was no
>   match at all from the cache.  Now we use the fact that the paths
>   "A", "A/B" and "A/B/C" is already tested, and we only need to do an

is -> are

>   lstat() call on "A/B/C/E".
> 
> - We only cache/store the last path regardless of it's type.  Since the

it's -> its

>   cache functionality is always used with alphabetically sorted names
>   (at least it seams so for me), there is no need to store both the

seams -> seems

>   last symlink-leading path and the last real-directory path.  Note
>   that if the cache is not called with (mostly) alphabetically sorted
>   names, neither the old, nor this new one, would be very effective.
> 
> - We also can cache the fact that a directory does not exist.
>   Previously we could end up doing lots of lstat() calls for a removed
>   directory which previously contained lots of files.  Since we
>   already have simplified the cache functionality and only store the
>   last path (see above), this new functionality was easy to add.
> 
> - Previously, when symlink A/B/C/S was cached/stored in the
>   symlink-leading path, and A/B/C/file.c was called for, it was not
>   easy to use the fact that we already known that the paths "A", "A/B"

known -> knew

>   and "A/B/C" is real directories.  Since we now only store one single

is -> are

>   path (the last one), we also get similar logic for free regarding
>   the new "non-exsisting-directory-cache".
> 
> - Avoid copying the first path components of the name 2 zillions times

zillions -> zillion

>   when we tests new path components.  Since we always cache/store the

tests -> test

>   last path, we can copy each component as we test those directly into
>   the cache.  Previously we ended up doing a memcpy() for the full
>   path/name right before each lstat() call, and when updating the
>   cache for each time we have tested an new path component.

an -> a

> 
> - We also use less memory, that is PATH_MAX bytes less memory on the

is -> is,

>   stack and PATH_MAX bytes less memory on the heap.

Cheers,

--Pete

  reply	other threads:[~2009-01-09 10:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-07 13:24 [PATCH/RFC v3 0/2] git checkout: optimise away lots of lstat() calls Kjetil Barvik
2009-01-07 13:24 ` [PATCH/RFC v3 1/2] Optimised, faster, more effective symlink/directory detection Kjetil Barvik
2009-01-09 10:20   ` Pete Harlan [this message]
2009-01-07 13:24 ` [PATCH/RFC v3 2/2] create_directories() inside entry.c: only check each directory once! Kjetil Barvik

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=496724E2.6010907@pcharlan.com \
    --to=pgit@pcharlan.com \
    --cc=barvik@broadpark.no \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.