doc/todo/optimize_simple_dependencies.mdwn

   1 [[!template id=gitbranch branch=smcv/ready/depends-exact author="[[smcv]]"]]
   2
   3 I'm still trying to optimize ikiwiki for a site using
   4 [[plugins/contrib/album]], and checking which pages depend on which pages
   5 is still taking too long. Here's another go at fixing that, using [[Will]]'s
   6 suggestion from [[todo/should_optimise_pagespecs]]:
   7
   8 > A hash, by itself, is not optimal because
   9 > the dependency list holds two things: page names and page specs.  The hash would
  10 > work well for the page names, but you'll still need to iterate through the page specs.
  11 > I was thinking of keeping a list and a hash.  You use the list for pagespecs
  12 > and the hash for individual page names.  To make this work you need to adjust the
  13 > API so it knows which you're adding.  -- [[Will]]
  14
  15 If you have P pages and refresh after changing C of them, where an average
  16 page has E dependencies on exact page names and D other dependencies, this
  17 branch should drop the complexity of checking dependencies from
  18 O(P * (D+E) * C) to O(C + P*E + P*D*C). Pages that use inline or map have
  19 a large value for E (e.g. one per inlined page) and a small value for D (e.g.
  20 one per inline).
  21
  22 Benchmarking:
  23
  24 Test 1: a wiki with about 3500 pages and 3500 photos, and a change that
  25 touches about 350 pages and 350 photos
  26
  27 Test 2: the docwiki (about 700 objects not excluded by docwiki.setup, mostly
  28 pages), docwiki.setup modified to turn off verbose, and a change that touches
  29 the 98 pages of plugins/*.mdwn
  30
  31 In both tests I rebuilt the wiki with the target ikiwiki version, then touched
  32 the appropriate pages and refreshed.
  33
  34 Results of test 1: without this branch it took around 5:45 to rebuild and
  35 around 5:45 again to refresh (so rebuilding 10% of the pages, then deciding
  36 that most of the remaining 90% didn't need to change, took about as long as
  37 rebuilding everything). With this branch it took 5:47 to rebuild and 1:16
  38 to refresh.
  39
  40 Results of test 2: rebuilding took 14.11s without, 13.96s with; refreshing
  41 three times took 7.29/7.40/7.37s without, 6.62/6.56/6.63s with.
  42
  43 (This benchmarking was actually done with my [[plugins/contrib/album]] branch,
  44 since that's what the huge wiki needs; that branch doesn't alter core code
  45 beyond the ready/depends-exact branch point, so the results should be
  46 equally valid.)
  47
  48 --[[smcv]]
  49
  50 > Now [[merged|done]] --[[smcv]]
  51
  52 ----
  53
  54 > We discussed this on irc; I had some worries that things may have been
  55 > switched to `add_depends_exact` that were not pure page names. My current
  56 > feeling is it's all safe, but who knows. It's easy to miss something.
  57 > Which makes me think this is not a good interface.
  58 >
  59 > Why not, instead, make `add_depends` smart. If it's passed something
  60 > that is clearly a raw page name, it can add it to the exact depends hash.
  61 > Else, add it to the pagespec hash. You can tell if it's a pure page name
  62 > by matching on `$config{wiki_file_regexp}`.
  63
  64 >> Good thinking. Done in commit 68ce514a 'Auto-detect "simple dependencies"',
  65 >> with a related bugfix in e8b43825 "Force %depends_exact to lower case".
  66 >>
  67 >> Performance impact: Test 2 above takes 0.2s longer to rebuild (probably
  68 >> from all the calls to lc, which are, however, necessary for correctness)
  69 >> and has indistinguishable performance for a refresh.
  70 >>
  71 >> Test 1 took about 6 minutes to rebuild and 1:25 to refresh; those are
  72 >> pessimistic figures, since I've added 90 more photos and 90 more pages
  73 >> (both to the wiki as a whole, and the number touched before refreshing)
  74 >> since testing the previous version of this branch. --[[smcv]]
  75
  76 > Also I think there may be little optimisation value left in
  77 > 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency
  78 > lists will be much shorter.
  79
  80 >> You're probably right, but IMO it's not worth reverting it - a set (hash with
  81 >> dummy values) is still the right data structure. --[[smcv]]
  82
  83 > Sounds like inline pagenames has an already exstant bug WRT
  84 > pages moving, which this should not make worse. Would be good to verify.
  85
  86 >> If you mean the standard "add a better match for a link-like construct" bug
  87 >> that also affects sidebar, then yes, it does have the bug, but I'm pretty
  88 >> sure this branch doesn't make it any worse. I could solve this at the cost
  89 >> of making pagenames less useful for interactive use, by making it not
  90 >> respect [[ikiwiki/subpage/LinkingRules]], but instead always interpret
  91 >> its paths as relative to the top of the wiki - that's actually all that
  92 >> [[plugins/contrib/album]] needs. --[[smcv]]
  93
  94 > Re coding, it would be nice if `refresh()` could avoid duplicating
  95 > the debug message, etc in the two cases. --[[Joey]]
  96
  97 >> Fixed in commit f805d566 "Avoid duplicating debug message..." --[[smcv]]