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
next prev parent 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).