From: Joey Hess Date: Mon, 12 Apr 2010 20:46:38 +0000 (-0400) Subject: update X-Git-Tag: 3.20100427~174 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=aaaef740107aacd8f6987711da6895c02e4473ad;p=ikiwiki.git update --- diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn index 33c825641..901e143a7 100644 --- a/doc/todo/smarter_sorting.mdwn +++ b/doc/todo/smarter_sorting.mdwn @@ -16,15 +16,9 @@ more expensive than sorting. (Also, influence calculation complicates doing that.) 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 -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)). +cull the M top pages without sorting the rest. -> The patch below implements this, perhaps not as efficiently as possible. -> It speeds up building just the top page of my blog by 1 second (out of -> 18). +> The patch below implements this. > > But, I have not thought enough about influence calculation. > 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 > from all the top successful matches, only an arbitrary group of > 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]] 
 diff --git a/IkiWiki.pm b/IkiWiki.pm