]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/todo/should_optimise_pagespecs.mdwn
Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
[ikiwiki.git] / doc / todo / should_optimise_pagespecs.mdwn
index 61458d9728554881ec47f86cc6f91efe2c9e6ddb..9d2611249ed42c272c5b380b5349d3fcb8784e8f 100644 (file)
@@ -79,6 +79,8 @@ I can think about reducung the size of my wiki source and making it available on
 > 
 > --[[Joey]]
 
+[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]]
+
 >> I've been looking at optimizing ikiwiki for a site using
 >> [[plugins/contrib/album]] (which produces a lot of pages) and it seems
 >> that checking which pages depend on which pages does take a significant
@@ -96,4 +98,48 @@ I can think about reducung the size of my wiki source and making it available on
 >>>> I haven't actually deleted it), because the "or" operation is now done in
 >>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]]
 
+[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]]
+
+>>>>> I've now added a patch to the end of that branch that deletes
+>>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in
+>>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support
+>>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]]
+
+---
+
+Some questions on your optimize-depends branch. --[[Joey]]
+
+In saveindex it still or'd together the depends list, but the `{depends}`
+field seems only useful for backwards compatability (ie, ikiwiki-transition
+uses it still), and otherwise just bloats the index.
+
+Is an array the right data structure? `add_depends` has to loop through the
+array to avoid dups, it would be better if a hash were used there. Since
+inline (and other plugins) explicitly add all linked pages, each as a
+separate item, the list can get rather long, and that single add_depends
+loop has suddenly become O(N^2) to the number of pages, which is something
+to avoid..
+
+> I was also thinking about this (I've been playing with some stuff based on the
+> `remove-pagespec-merge` branch).  A hash, by itself, is not optimal because
+> the dependency list holds two things: page names and page specs.  The hash would
+> work well for the page names, but you'll still need to iterate through the page specs.
+> I was thinking of keeping a list and a hash.  You use the list for pagespecs
+> and the hash for individual page names.  To make this work you need to adjust the
+> API so it knows which you're adding.  -- [[Will]]
+
+Also, since a lot of places are calling add_depends in a loop, it probably
+makes sense to just make it accept a list of dependencies to add. It'll be
+marginally faster, probably, and should allow for better optimisation
+when adding a lot of depends at once.
+
+In Render.pm, we now have a triply nested loop, which is a bit
+scary for efficiency. It seems there should be a way to
+rework this code so it can use the optimised `pagespec_match_list`,
+and/or hoist some of the inner loop calculations (like the `pagename`)
+out.
+
+Very good catch on img/meta using the wrong dependency; verified in the wild!
+(I've cherry-picked those bug fixes.)
+
 [[!tag wishlist patch patch/core]]