response

1 files changed, 5 insertions, 2 deletions

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 2ce1de6a4..0aca74be2 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -165,7 +165,6 @@ That earlier version of the branch is also available for comparison:
 >>>>>>> I've kept the semantics from `report` as-is, then:
 >>>>>>> e.g. `sort="age -title"`. --s
 
->>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
@@ -190,7 +189,7 @@ That nasty perl optimisation is still worthwhile:
 	Benchmark: timing 10000 iterations of a, b, c...
 	         a: 80 wallclock secs (76.74 usr +  0.05 sys = 76.79 CPU) @ 130.23/s (n=10000)
 	         b: 112 wallclock secs (106.14 usr +  0.20 sys = 106.34 CPU) @ 94.04/s (n=10000)
-                 c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
+	         c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
 
 Unfortunatly, I think that c is closest to the new implementation.
 --[[Joey]]
@@ -217,6 +216,10 @@ Unfortunatly, I think that c is closest to the new implementation.
 > is sorted. Or, it might be useful to do the filtering first, then
 > sort the sub-list thus produced, then finally apply the limit? --s
 
+>> Yes, it was deliberate, pagespec matching can be expensive enough that
+>> needing to sort a lot of pages seems likely to be less work. (I don't
+>> remember what benchmarking was done though.) --[[Joey]] 
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])