Greg Stein <gstein@lyra.org> writes:
> > In our current discipline, editor batons are supposed to be
> > self-managing types, meaning they allocate themselves in a subpool (of
> > the parent baton's pool) and destroy the subpool upon close. This isn't
> > fashionable, but it does limit memory usage.
>
> Yup, but many editors are not doing that. I keep running into them. The
> trace editor, the composition editor, ra_dav has one or two, etc.
I thought this was planned lossage -- we consciously decided to depend
on profiling information to decide how particular editors would use
subpools. Now you've gotten some profiling information, and we can
change how particular editors use subpools :-).
I doubt the issue is that it's somehow harder to do good memory
management in the current editor interface, rather it's that we chose
not to do so until we had more data on what "good" means. The
advanatges of the new interface don't seem overwhelming to me -- it
takes memory management decisions away from editors and gives them to
editor drivers instead. This could be a slight win, as there are
probably fewer drivers than editors, but on the other hand, it's the
editor who knows what work it's doing, and I don't see how in general
the editor drivers can make good decisions about subpool creation.
> The new interface makes it easier for the editors to Do It Right. Currently,
> all the editor implementations must deal with the subpool stuff, or else
> they will be doing it wrong.
Except that the subpool stuff can be different for different editors.
I dunno. I'm certainly not wedded to our current editor interface,
just am not seeing a big advantage to this particular change...
-K
---------------------------------------------------------------------
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:09 2006