Merge commit 'upstream/master'

[git.ikiwiki.info.git] / doc / todo / optimisations.mdwn

diff --git a/doc/todo/optimisations.mdwn b/doc/todo/optimisations.mdwn
index 13a270b8fa36c30be7bf8ca9e18650a1522e22c7..b8c4fa0dabdf387dcd23a4015750f2fa18f37922 100644 (file)
--- a/doc/todo/optimisations.mdwn
+++ b/doc/todo/optimisations.mdwn
@@ -1,21 +1,15 @@
-* Don't render blog archive pages unless a page is added/removed. Just
-  changing a page doesn't affect the archives as they show only the title.
+Ikiwiki has already been optimised a lot, however..

 
 * Look at splitting up CGI.pm. But note that too much splitting can slow
   perl down.
 
 
 * Look at splitting up CGI.pm. But note that too much splitting can slow
   perl down.
 

-* The backlinks code turns out to scale badly to wikis with thousands of
-  pages. The code is O(N^2)! It's called for each page, and it loops
-  through all the pages to find backlinks.
+  > It's split enough, or possibly more than enough, now. :-)

 
 

-  Need to find a way to calculate and cache all the backlinks in one pass,
-  which could be done in at worst O(N), and possibly less (if they're
-  stored in the index, it could be constant time). But to do this, there
-  would need to be a way to invalidate or update the cache in these
-  situations:
+* The backlinks calculation code is still O(N^2) on the number of pages.
+  If backlinks info were stored in the index file, it would go down to
+  constant time for iterative builds, though still N^2 for rebuilds.

 
 

-  - A page is added. Note that this can change a backlink to point to 
-    the new page instead of the page it pointed to before.
-  - A page is deleted. This can also change backlinks that pointed to that
-    page.
-  - A page is modified. Links added/removed.
+  > Seems to be O(Num Pages * Num Links in Page), or effectively O(N)
+  > pages for most wikis.
+
+[[done]]