git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marco Costalba" <mcostalba@gmail.com>
To: "Junio C Hamano" <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [WISH] Store also tag dereferences in packed-refs
Date: Sun, 19 Nov 2006 01:28:50 +0100	[thread overview]
Message-ID: <e5bfff550611181628o41e11652ycd17ddad5dd21225@mail.gmail.com> (raw)
In-Reply-To: <7vac2oefuz.fsf@assigned-by-dhcp.cox.net>

>
> A quick one that is to the point to solve "your" problem.
>
>         show-ref -d
>

I was out for dinner, just come back home.

Some quick tests with show-ref -d instead of peek-remote:

- git tree 2374ms
- linux tree 2225ms

Not a big change. I reboot before each test to have a guaranteed cold cache.

Tested also with show-ref only, not useful to me, but just as a comparison.

- git tree 1420ms
- linux tree 1021ms

Better, but still slower then what I would expected.

In both case CPU load is low, processes are heavily I/O bound, so
avoiding some fork does not save the day.

Please, tell me if you want me to run some kind of additional test.

> I wonder how fast update-server-info is under the same condition
> with your earlier timing.
>
> I am not suggesting you to use update-server-info.  The reason I
> am wondering about it are:
>
>  (1) traditionally, "peek-remote ." has been the only way to get
>      to that information, so you have every right to keep doing
>      so;
>
>  (2) however, even with presense of packed-refs, upload-pack
>      that is invoked by peek-remote needs to consult unpacked
>      refs first and then fall back to packed-refs, and only
>      using the ^{} information "cached" in packed-refs file and
>      computing ^{} itself when dealing with unpacked refs means
>      more code, which we need to assess the pros-and-cons.
>
>  (3) another inefficiency of using "peek-remote ." is that it
>      spawns another process in the "remote" repo and talks with
>      it.
>
> So storing this information making upload-pack to reuse it when
> it can might make things go faster for other applications but
> first I wanted to know how much overhead is incurred in the
> extra upload-pack process, and time update-server-info needs to
> prepare the info in .git/info/refs would be a way to get a rough
> estimate for that (you subtract that from "peek-remote ." time).
>

It's to late to understand this part of your e-mail ;-) I will read
better tomorrow.

Thanks

  reply	other threads:[~2006-11-19  0:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-18  9:15 [WISH] Store also tag dereferences in packed-refs Marco Costalba
2006-11-18 18:38 ` Junio C Hamano
2006-11-18 18:43   ` Petr Baudis
2006-11-18 18:47     ` Marco Costalba
2006-11-18 19:04       ` Junio C Hamano
2006-11-19  0:28         ` Marco Costalba [this message]
2006-11-19  1:11           ` Linus Torvalds
2006-11-19  1:40             ` Junio C Hamano
2006-11-19  1:45               ` Junio C Hamano
2006-11-19  1:59                 ` Linus Torvalds
2006-11-19  9:40             ` Marco Costalba
2006-11-19 18:05               ` Linus Torvalds
2006-11-19 19:07                 ` Marco Costalba
2006-11-19 20:09                   ` Marco Costalba
2006-11-19 20:36                     ` Linus Torvalds
2006-11-19 20:44                       ` Linus Torvalds
2006-11-19 21:01                       ` Junio C Hamano
2006-11-19 21:14                         ` Linus Torvalds
2006-11-19 21:24                           ` Jakub Narebski
2006-11-19 23:36                             ` Linus Torvalds
2006-11-20  2:35                               ` Junio C Hamano
2006-11-20  9:40                                 ` Jakub Narebski
2006-11-20 12:56                                   ` Marco Costalba
2006-11-20 16:29                                 ` Linus Torvalds
2006-11-20 19:32                                   ` Junio C Hamano
2006-11-19 22:25                       ` Marco Costalba
2006-11-19 23:26                         ` Linus Torvalds
2006-11-19 20:18                   ` Linus Torvalds
     [not found] ` <200611201154.08732.jnareb@gmail.com>
     [not found]   ` <7vu00u2wln.fsf@assigned-by-dhcp.cox.net>
2006-11-20 11:33     ` Jakub Narebski

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=e5bfff550611181628o41e11652ycd17ddad5dd21225@mail.gmail.com \
    --to=mcostalba@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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).