On Thu, Feb 21, 2002 at 04:33:15PM -0600, Karl Fogel wrote:
> 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 :-).
*ALL* editors need to use subpools for their dir and file batons. That is
what I found. Even the little doodad ones that we figured were no big deal.
So... since they *all* do, I thought it best to encode that into the
interface itself, so that the policy is much more explicit.
> 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
Yup. We've now learned that they all need to do it :-)
> 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.
Yup. But in the process, I also believe it is encoding that policy a bit
more in the interface. Rather than making assumptions about what the editor
will do, now there are explicit pools for the editor to use at the different
steps.
> This could be a slight win, as there are
> probably fewer drivers than editors,
There are fewer drivers, yes.
> 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.
Remember: the caller always knows more about the pattern of calls into any
given interface. If the caller is going to be looping, then it is going to
want to use subpools.
*Inside* an API, it cannot know whether it will be called once or multiple
times. Using a subpool for a particular invocation isn't beneficial, over
allowing the caller to deal with it.
[ for an invocation, the peak memory is still PARENT + SUBPOOL; thus, you
can just leave the memory in PARENT for the same peak; the caller will
clear that pool if a second call is going to use that same pool, and it
wants to keep an overall peak low. ]
Inside of the editor, if a particular call is going to loop, then it will
apply the same logic: use subpools to manage the peak.
> > 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.
We devised the strategy a long time ago (after some exploration :-), but the
editor does not follow that pattern. And that strategy is "1) leave it to
the caller to manage lifetimes. 2) if you have an unbounded loop, then use a
subpool."
> I dunno. I'm certainly not wedded to our current editor interface,
> just am not seeing a big advantage to this particular change...
Maybe now? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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