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 ...
From: Zack Brown <hidden> Date: 2016-06-15 22:41:57
On Sat, May 14, 2005 at 04:17:44AM -0700, Junio C Hamano wrote:
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.
So if this design is changed to suit -u, would a further redesign be needed
to support an option to filter on keywords in the body of the changelog
entry? Perhaps this will result in a net slowdown for the usual case of just
grabbing all log entries.
Be well,
Zack
Not that I
would want to solve this myself ...
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Petr Baudis <hidden> Date: 2016-06-15 22:41:57
Dear diary, on Sat, May 14, 2005 at 04:23:25PM CEST, I got a letter
where Zack Brown [off-list ref] told me that...
On Sat, May 14, 2005 at 04:17:44AM -0700, Junio C Hamano wrote:
quoted
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.
So if this design is changed to suit -u, would a further redesign be needed
to support an option to filter on keywords in the body of the changelog
entry? Perhaps this will result in a net slowdown for the usual case of just
grabbing all log entries.
I admit not looking at this code for a rather long time, but what about
just telling the commit parser what stuff are you interested in and it
would leave the rest of the structure fields NULL? That would mean only
slight memory usage increase and basically no time increase.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:41:57
On Sat, 14 May 2005, Junio C Hamano wrote:
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.
They aren't designed for the immediate users; they're implemented for the
immediate users. Feel free to add more fields as you need them. The
current selection is based on only adding things when there's a user for
them.
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.
Existance is the primary thing, and everything else was added as
needed. (Pure connectivity is a bit special, because it's a property of
generic objects so that fsck-cache doesn't need to know about particular
types of objects unless there are particular things to check about them)
If you need more fields, let me know, and I'll figure out how to include
them.
-Daniel
*This .sig left intentionally blank*