[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [PATCH] arch speedups on big trees
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [PATCH] arch speedups on big trees |
Date: |
Fri, 30 Jan 2004 11:34:10 -0800 (PST) |
> From: Aaron Bentley <address@hidden>
> On Wed, 2004-01-28 at 13:40, Tom Lord wrote:
> > 2) "sliding" libraries -- that try to keep the number of revisions in
> > a version constant by recycling old revisions (honoring the locking
> > protocol)
> Sliding libraries seem to be a generalization of "current revision"
> libraries. If "current revision" libraries are significantly easier to
> implement, it might be worthwile to do that instead.
It _seems_ to me that the "hard part" of this is the need for a
locking protocol on library revisions. Both "sliding" and "current
revision" libraries would need locking.
The only difference between "sliding" and "current revision" libraries
would be the algorithm for picking which revision to recycle, right?
> I'm planning on revising build_revision so that it can work backwards
> from a recent revision to an older revision.
Hurrah!
> > 6) If users balk at the edge cases resulting from having a non-default
> > library path that doesn't include the "special string" for in-tree
> > libraries, then perhaps add that implicitly to the end of the
> > add-path.
> These changes will make some form of greedy library required. It will
> change the form of nasty surprise from "dammit, I didn't want a
> pristine," to "dammit, I need to explicitly add a revision before I can
> continue". This is true whether or not the "special string" is always a
> member of the library path.
That's not quite accurate but it's not important. Yes, I agree that
the new configuration burdens are not a problem.
> > It's also a nifty plan because it's (finally!) an occaision where we
> > can probably wind up _removing_ more code from tla than is being added
> Say, what about unifying cmd_get() with find_or_make_local_copy()? Is
> there any reason for duplicating functionality this way?
Not much of one.
As I recall, the logic about when to add things to a library is
slightly different between them -- it might require some new
parameterization in local-cache.c to be able to factor stuff out of
cmd_get.
-t
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, (continued)
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Robin Green, 2004/01/29
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Tom Lord, 2004/01/29
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Andrew Suffield, 2004/01/29
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Aaron Bentley, 2004/01/28
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Chris Mason, 2004/01/28
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Aaron Bentley, 2004/01/30
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees,
Tom Lord <=
- Re: [Gnu-arch-users] [PATCH] arch speedups on big trees, Aaron Bentley, 2004/01/28