instead of over and over. Typical speedup is ~4x. Max possible speedup:

  8x.
* Add "scan" parameter to hook(), which is used to make the hook be called
  during the scanning pass, as well as the render pass. The meta and tag
  plugins need to use the new scan parameter, so will any others that modify
  %links.
* Now that links are calculated in a separate pass, it can also 
  precalculate backlinks in one pass, which is O(N^2) instead of the
  previous code that was O(N^3). A very nice speedup for wikis with lots
  (thousands) of pages.

4 files changed, 19 insertions, 17 deletions

diff --git a/doc/plugins/contrib/googlemaps.mdwn b/doc/plugins/contrib/googlemaps.mdwn
index 58ccf5adc..30f630a2c 100644
--- a/doc/plugins/contrib/googlemaps.mdwn
+++ b/doc/plugins/contrib/googlemaps.mdwn
@@ -1,5 +1,5 @@
 [[template id=plugin name=googlemaps author="Christian Mock"]]
-[[tag special-purpose]]
+[[tag type/special-purpose]]
 [[meta title="googlemaps (third-party plugin)"]]
 
 `googlemaps` is a plugin that allows using the [Google Maps API][2]
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 8492b1756..5cace0911 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -30,6 +30,12 @@ hook, a "id" paramter, which should be a unique string for this plugin, and
 a "call" parameter, which is a reference to a function to call for the
 hook.
 
+An optional "scan" parameter, if set to a true value, makes the hook be
+called during the preliminary scan that ikiwiki makes of updated pages,
+before begining to render pages. This parameter should be set to true if
+the hook modifies data in `%links`. Note that doing so will make the hook
+be run twice per page build, so avoid doing it for expensive hooks.
+
 ## Types of hooks
 
 In roughly the order they are called.
@@ -64,6 +70,14 @@ Runs on the raw source of a page, before anything else touches it, and can
 make arbitrary changes. The function is passed named parameters `page` and
 `content` and should return the filtered content.
 
+### scan
+
+	hook(type => "scan", id => "foo", call => \&scan);
+
+This is identical to a preprocess hook (see below), except that it is
+called in the initial pass that scans pages for data that will be used in
+later passes. Scan hooks are the only hook that should modify 
+
 ### preprocess
 
 Adding a [[PreProcessorDirective]] is probably the most common use of a
diff --git a/doc/roadmap.mdwn b/doc/roadmap.mdwn
index b393f254f..701365a25 100644
--- a/doc/roadmap.mdwn
+++ b/doc/roadmap.mdwn
@@ -18,7 +18,7 @@ Released 29 April 2006.
 * [[Tags]] _(status: fair)_
 * Should have fully working [[todo/utf8]] support. _(status: good)_
 * [[Optimised_rendering|todo/optimisations]] if possible. Deal with other
-  scalability issues. _(status: something like 9x speedup 1.0!)_
+  scalability issues. _(status: should be faster, need to get numbers)_
 * Improved [[todo/html]] stylesheets and templates.
 * Improved scalable [[logo]]. _(status: done)_
 * Support for at other revision control systems aside from svn.
diff --git a/doc/todo/optimisations.mdwn b/doc/todo/optimisations.mdwn
index 13a270b8f..0eb830cd0 100644
--- a/doc/todo/optimisations.mdwn
+++ b/doc/todo/optimisations.mdwn
@@ -4,18 +4,6 @@
 * 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.
-
-  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:
-
-  - 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.
+* 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.