From: Junio C Hamano <junkio@cox.net>
To: Petr Baudis <pasky@ucw.cz>
Cc: Zack Brown <zbrown@tumblerings.org>,
git@vger.kernel.org, torvalds@osdl.org
Subject: Re: speeding up cg-log -u
Date: Sat, 14 May 2005 04:17:44 -0700 [thread overview]
Message-ID: <7vk6m212g7.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050514103937.GA3905@pasky.ji.cz> (Petr Baudis's message of "Sat, 14 May 2005 12:39:37 +0200")
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Dear diary, on Sat, May 14, 2005 at 11:50:24AM CEST, I got a letter
PB> where Junio C Hamano <junkio@cox.net> told me that...
>> + buffer = read_sha1_file(item->object.sha1, type, &size);
PB> If it do that, I wonder how much speedup would be using this instead.
PB> But probably still significant one.
I would imagine so (only benchmark would tell), because you
would not spawn git-cat-file for each individual commit object.
Whenever I work with those "struct object" derivatives, I get
very frustrated by the fact that they are designed to cater only
to the need of very narrow immediate users. The first round of
tree objects did not even have names for each entry because the
only thing it cared about was connectivity checking, and for
that purpose callers would not care about what each blob or
subtree was referred as. Now when I want to use commit objects
I find that it only records the commit date (other than
connectivity information). It really appears that connectivity
is the primary thing and everything else is bolted on top.
Not wanting to keep the whole object because of their size is
understandable since the users of "struct object" derivatives
rarely if ever seem to free them once they get hold of them.
And not wanting to think ahead about what is worth keeping (like
names for tree entries back then, or commit author names) is
also understandable, but it still is frustrating. Not that I
would want to solve this myself ...
next prev parent reply other threads:[~2005-05-14 11:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-14 6:19 speeding up cg-log -u Zack Brown
2005-05-14 8:13 ` Junio C Hamano
2005-05-14 9:50 ` [PATCH] Add --author match to git-rev-list and git-rev-tree Junio C Hamano
2005-05-14 15:06 ` Zack Brown
2005-05-14 15:52 ` Petr Baudis
2005-05-14 16:02 ` Zack Brown
2005-05-14 10:39 ` speeding up cg-log -u Petr Baudis
2005-05-14 11:14 ` Petr Baudis
2005-05-14 11:17 ` Junio C Hamano [this message]
2005-05-14 14:23 ` Zack Brown
2005-05-14 14:40 ` Petr Baudis
2005-05-15 16:09 ` Daniel Barkalow
2005-05-16 8:13 ` Junio C Hamano
2005-05-16 15:38 ` Daniel Barkalow
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=7vk6m212g7.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=pasky@ucw.cz \
--cc=torvalds@osdl.org \
--cc=zbrown@tumblerings.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 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).