master
Joey Hess 2010-04-12 16:46:38 -04:00
parent 24fb346938
commit aaaef74010
1 changed files with 7 additions and 8 deletions

View File

@ -16,15 +16,9 @@ more expensive than sorting. (Also, influence calculation complicates
doing that.) doing that.)
Another option, when there is a limit on M pages to return, might be to Another option, when there is a limit on M pages to return, might be to
cull the M top pages without sorting the rest. This could be done using cull the M top pages without sorting the rest.
a variant of Ye Olde Bubble Sort. Take the first M pages, and (quick)sort.
Then for each of the rest, check if it is higher than the Mth page.
If it is, bubble it up so it's sorted.
If not, throw it out (that's the fast bit and why this is not O(N^2)).
> The patch below implements this, perhaps not as efficiently as possible. > The patch below implements this.
> It speeds up building just the top page of my blog by 1 second (out of
> 18).
> >
> But, I have not thought enough about influence calculation. > But, I have not thought enough about influence calculation.
> I need to figure out which pagespec matches influences need to be > I need to figure out which pagespec matches influences need to be
@ -36,6 +30,11 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
> zero) number of failed matches. New code does not accumulate influences > zero) number of failed matches. New code does not accumulate influences
> from all the top successful matches, only an arbitrary group of > from all the top successful matches, only an arbitrary group of
> successes and some failures. > successes and some failures.
>
> Also, by the time I finished this, it was not measuarably faster than
> the old method. At least not with a few thousand pages; it
> might be worth revisiting this sometime for many more pages? [[done]]
> --[[Joey]]
<pre> <pre>
diff --git a/IkiWiki.pm b/IkiWiki.pm diff --git a/IkiWiki.pm b/IkiWiki.pm