gnu-arch-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]