[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: situations where cached revisions are not so go

From: Jason McCarty
Subject: Re: [Gnu-arch-users] Re: situations where cached revisions are not so good
Date: Sun, 28 Sep 2003 18:57:34 -0400
User-agent: Mutt/1.5.4i

I suppose at this point it would be most fruitful to place some
differently-arranged summaries in a big tree, and determine how each
algorithm would perform given random sets of pristines and goals.

This could be done abstractly, or in a real tree, with the cost metric
being numbers of deltas applied or total delta size, respectively.
Cachedrevs may or may not be present, but I would probably only put them
with continuations.

Evaluation criteria would be how close to optimal the resultant path is,
and how many revisions it had to examine to find its solution.

Possible placements of summaries include:
  1. Every Nth revision, spanning N revisions. Place a summary every N^2
     revisions as well (to summarize the summaries). Extra points for
     varying the length (density) of summaries dependent on local
     revision size. This is the case my algorithm is designed to
     exploit, and SPF should do well here too, but I suspect it will
     have to examine more revisions.
  2. Random placement and length of summaries. This is an unlikely
     placement strategy, but SPF might perform better on it.
  3. I dunno, whatever else you can think of that sounds like an optimal
     placement strategy. As I mentioned before, I think (1) is nearly
     optimal regardless of algorithm.

Hopefully an evaluation like this can tell us how accurate our
respective intuitions are.


reply via email to

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