ikiwiki/doc/todo/optimisations.mdwn

Ikiwiki has already been optimised a lot, however..

* 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.

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

* 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.
update 2006-10-28 07:10:13 +02:00			`Ikiwiki has already been optimised a lot, however..`

add 2006-03-24 05:04:37 +01:00			`* 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.`

			`* Look at splitting up CGI.pm. But note that too much splitting can slow`
			`perl down.`
* Add a separate pass to find page links, and only render each page once, instead of over and over. This is up to 8 times faster than before! (This could have introduced some subtle bugs, so it needs to be tested extensively.) 2006-10-28 05:27:10 +02:00
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. 2006-10-28 07:07:56 +02:00			`* 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.`