From: Yasushi SHOJI <yashi@atmark-techno.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [patch] possible memory leak in diff.c::diff_free_filepair()
Date: Tue, 16 Aug 2005 12:05:16 +0900 [thread overview]
Message-ID: <8764u6ponn.wl@mail2.atmark-techno.com> (raw)
In-Reply-To: <7viry9le0g.fsf@assigned-by-dhcp.cox.net>
At Sat, 13 Aug 2005 14:31:59 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > oops. probably my english wasn't clear. my patch fixes
> > diff_free_filepair().
>
> When the command is run on linux-2.6 repository, virtual memory
> consumption of git-diff-tree command skyrockets to about half a
> gig, because it maps all files in two adjacent revisions of the
> entire kernel tree. But it seems to reclaim things reasonably
> well and goes back down to less than 10m when it starts to
> process the next commit pair.
it tunes out that, at least for my problem is to populating filespec
data in parepare_temp_file() and not freeing it after creating temp
file with prep_temp_blob().
parepare_temp_file() and diff_populate_filespec() has a lot in
similarity. so it'd be nice to refactor some. and re-introduce
diff_free_filespec_data() and call right after prep_temp_blob() in
prepare_temp_file().
Junio, did you also mean to clean-up these functions when you said in
the thread of "Re: gitweb - option to disable rename detection"?
regards,
--
yashi
next prev parent reply other threads:[~2005-08-16 3:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-13 10:58 [patch] possible memory leak in diff.c::diff_free_filepair() Yasushi SHOJI
2005-08-13 19:30 ` Junio C Hamano
2005-08-13 21:09 ` Yasushi SHOJI
2005-08-13 21:31 ` Junio C Hamano
2005-08-16 3:05 ` Yasushi SHOJI [this message]
2005-08-16 4:32 ` Junio C Hamano
2005-08-21 7:14 ` Yasushi SHOJI
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=8764u6ponn.wl@mail2.atmark-techno.com \
--to=yashi@atmark-techno.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.