urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

response

master
Joey Hess 2010-04-05 15:28:54 -04:00
parent 861080b918
commit 10f4695abd
1 changed files with 5 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/todo/allow_plugins_to_add_sorting_methods.mdwn
View File

@ -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: >>>>>>> I've kept the semantics from `report` as-is, then:
>>>>>>> e.g. `sort="age -title"`. --s >>>>>>> e.g. `sort="age -title"`. --s
>>>>>
>>>>> Perhaps we could borrow from `meta updated` and use `update_age`? >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
>>>>> `updateage` would perhaps be a more normal IkiWiki style - but that >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
>>>>> makes me think that updateage is a quantity analagous to tonnage or >>>>> 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... 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) 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) 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. Unfortunatly, I think that c is closest to the new implementation.
--[[Joey]] --[[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 > 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 > 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 ## Documentation from sort-package branch
### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]]) ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])