From aaaef740107aacd8f6987711da6895c02e4473ad Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 12 Apr 2010 16:46:38 -0400 Subject: update --- doc/todo/smarter_sorting.mdwn | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'doc/todo/smarter_sorting.mdwn') 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
-- 
cgit v1.2.3