From: Linus Torvalds <torvalds@osdl.org>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH 0/3] Remove more parsers
Date: Tue, 31 Jan 2006 09:16:00 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0601310905000.7301@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0601291645060.25300@iabervon.org>
On Sun, 29 Jan 2006, Daniel Barkalow wrote:
>
> I'll look into discarding the struct trees after use (since we're not
> keeping flags on them, or storing references to them long-term), so we can
> use the same parser without worse memory behavior. It does seem to take a
> bunch more memory (and, oddly, be very slow) as I currently have it.
Really, trying to use "struct tree" just is _broken_.
Even if you start freeing the memory, performance will absolutely _suck_.
You'll be using a "malloc()" (and eventually, a "free()") and copying the
tree entries around for absolutely zero gain. You'll make things follow
pointers and have indirection, instead of just walking the data structure
directly.
IOW, it will be about ten times more expensive in CPU time, in the most
performance-critical part of git.
I would actually argue that if you want to use a common structure, try to
convert existing users of "struct tree" to the "struct tree_desc"
iterators. Yes, their use is a little awkward, but there's really no way
you can use anything but the fast ones for tree diffing.
The "struct tree_desc" can only be used for traversing a tree linearly in
one order, but I bet that nobody really ever does anything else.
To make "struct tree_desc" more generic, you'd obviously have to export
the "update_tree_entry()" and "extract()" functions (and the latter would
probably need to be re-named to "extract_tree_entry()").
Oh, and to make freeign the tree entry a bit simpler, you'd probably want
to replace
void *buf
unsigned int size;
with a
const void *const tree_base;
const unsigned int tree_size;
unsigned int offset;
so that you'd just update "offset" and leave tree_base/size untouched (to
make freeing easier - right now the person who populates the "struct
tree_desc" has to free the thing by hand).
Linus
prev parent reply other threads:[~2006-01-31 17:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-29 19:04 [PATCH 0/3] Remove more parsers Daniel Barkalow
2006-01-29 19:04 ` [PATCH 1/3] Use struct tree in tar-tree Daniel Barkalow
2006-01-29 19:05 ` [PATCH 2/3] Use struct commit " Daniel Barkalow
2006-01-29 19:05 ` [PATCH 3/3] Use struct tree in diff-tree Daniel Barkalow
2006-01-31 16:53 ` Linus Torvalds
2006-01-31 21:20 ` Junio C Hamano
2006-01-31 21:49 ` Daniel Barkalow
2006-01-31 22:07 ` Linus Torvalds
2006-01-29 20:26 ` [PATCH 0/3] Remove more parsers Junio C Hamano
2006-01-29 22:05 ` Daniel Barkalow
2006-01-31 17:16 ` Linus Torvalds [this message]
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=Pine.LNX.4.64.0601310905000.7301@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=barkalow@iabervon.org \
--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).