gstein@tigris.org wrote:
>Author: gstein
>Date: 2002-01-27 13:54 GMT
>New Revision: 1077
>
>Modified:
> trunk/subversion/include/svn_delta.h
> trunk/subversion/libsvn_delta/delta.h
> trunk/subversion/libsvn_delta/svndiff.c
> trunk/subversion/libsvn_delta/text_delta.c
> trunk/subversion/libsvn_delta/vdelta.c
> trunk/subversion/libsvn_fs/reps-strings.c
> trunk/subversion/libsvn_ra_dav/fetch.c
> trunk/subversion/tests/libsvn_delta/vdelta-test.c
>Log:
>Clarify the lifetime issues around the svn_txdelta_window_t
>structure. In some cases, it was created as a "free standing" object
>in its own subpool and svn_txdelta_free_window() needed to be
>called. Other times, it was a structure on the stack.
>
>Now, it is clearer that the code creating the window is responsible
>for cleaning it, and how they clean it. If svn_txdelta_next_window()
>is used, then it is passed a pool, so the caller knows to clear the
>pool to toss the window. If the caller constructs a window manually,
>then they also know how to clean it up.
>
>NOTE: this change may also dramatically fix our memory consumption. I
>found that the vdelta hash tables were allocated in the stream's pool,
>rather than for each window. I'm not positive what the resulting peak
>was, but it appeared to be on the order of a pointer for each byte in
>the source *and* target files that were being diff'd. (e.g. compare
>
Ouch, ouch!
>two one megabyte files and you'd get 8 megabytes of pointer data).
>Basically, the wrong pool was passed to svn_txdelta__vdelta().
>
Ah, then it wasn't my fault! (sighs with relief) :-)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006