Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

diff --combined doc/todo/should_optimise_pagespecs.mdwn
index 7a2e7d45fa781d7afeea764edb5a13111f347ae5,5dd3b1e34492aa83f91788406cdba4f1dfd81115..4b4e267f0030df6ab86a8e3cac8c26a6613a50fb
--- 1/doc/todo/should_optimise_pagespecs.mdwn
--- 2/doc/todo/should_optimise_pagespecs.mdwn
+++ b/doc/todo/should_optimise_pagespecs.mdwn
@@@ -90,8 -90,6 +90,8 @@@ I can think about reducung the size of 
  >> rather than a single pagespec. This does turn out to be faster, although
  >> not as much as I'd like. --[[smcv]]
  
 +>>> [[Merged|done]] --[[smcv]]
 +
  >>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]]
  
  >>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`).
@@@ -266,6 -264,9 +266,9 @@@ might well be experimental error, for t
  > `add_depends` had no effect. So, the commit message to
  > b6fcb1cb0ef27e5a63184440675d465fad652acf is actually wrong.. ? --[[Joey]] 
  
+ >> I'll try benchmarking again on the non-public wiki where I had the 4%
+ >> speedup. The docwiki is so small that 4% is hard to measure... --[[smcv]]
+ 
  Not saving {depends} to the index, using a hash instead of a list to
  de-duplicate, and allowing add_depends to take an arrayref instead of a single
  pagespec had no noticable positive or negative effect on this test.
@@@ -273,11 -274,17 +276,17 @@@
  > I see e4cd168ebedd95585290c97ff42234344bfed46c is still in your branch
  > though. I don't like using an arrayref, it could just take `($page, @depends)`.
  > and I don't see the need to keep it if it doesn't currently help.
- > 
+ 
+ >> I'll drop it. --[[smcv]]
+ 
  > Is there any reason to keep 7227c2debfeef94b35f7d81f42900aa01820caa3
  > if it doesn't improve speed?
  > --[[Joey]] 
  
+ >> I'll try benchmarking on a more complex wiki and see whether it has a
+ >> positive or negative effect. It does avoid being O(n**2) in number of
+ >> dependencies. --[[smcv]]
+ 
  Memoizing the results of pagename brought the rebuild time down to 14.06s
  and the refresh time down to 7.96/7.92/7.92, a significant win.
  
@@@ -285,6 -292,9 +294,9 @@@
  > called with a great many inputs.) Why did you chose to memoize it
  > explicitly rather than adding it to the memoize list at the top?
  
+ >> It does depend on global variables, so using Memoize seemed like asking for
+ >> trouble. I suppose what I did is equivalent to Memoize though... --[[smcv]]
+ 
  Refactoring to use pagespec_match_list looks more risky from a code churn
  point of view; rebuild now takes 14.35s, but refresh is only 7.30/7.29/7.28,
  another significant win.