This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Copies of the GCC repository
On Wed, 2005-11-23 at 00:58 +0100, Gabriel Dos Reis wrote:
> Russ Allbery <rra@stanford.edu> writes:
>
> | Daniel Jacobowitz <drow@false.org> writes:
> | > On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
> |
> | >> (2) Is it normal that "svk push" takes more than 5 minutes to complete?
> | >> If so, that does not match the speed argument I've seen for the
> | >> move to SVN.
> |
> | > SVN is fast. SVK, in many operations, seems to be quite slow (but fast
> | > on others).
> |
> | Part of the problem with svk is that for some reason it appears to devour
> | memory.
>
> That is very true -- I was depressed when "watching" svk with 'top'.
A lot of this was/is improper pool management[1] on the part of SVK
(dunno how bad it still is)
Subversion used to have a lot of this issue too, and fixed them one at a
time (mostly pre-1.0, but definitely some after).
If you email clkao, and tell him what ops are using tons of memory,
preferrably with simple reproduction recipes (IE "run svk status on this
directory, and memory usage will go up to 50 billion gigabytes"), he'll
likely just fix the problems very quickly. :)
That's how Daniel Jacobowitz got svk imports of the gcc repo working
without needing a billion gigabytes of memory AFAIK (clkao bugfixed and
provided him with an updated SVN::Mirror with some memory leaks fixed).
My experience is that he's very responsive to fixing bugs.
--Dan
[1] Subversion uses pools to manage memory lifetimes. Basically each
pool is a seperate heap you can allocate memory out of, free memory back
to, etc. Like obstacks, except you can have subpools that die either
explicitly or when their parent pool is freed, cleanups that can be run
when the pool is destroyed, and all sorts of neat things.
Most svn side operations create subpools for loops that may allocate
per-iteration memory due to calls to other functions, etc, and clear it
each iteration to avoid such per iteration allocations become too large.
Some don't. Some of the stuff that SVK has reimplemented probably needs
them but doesn't have them.
--Dan