-* Render each changed page only once. Currently pages are rendered up to 4
- times in worst case (8 times if there's an rss feed).
+Ikiwiki has already been optimised a lot, however..
- The issue is that rendering a page is used to gather info like the links
- on the page (and other stuff) that can effect rendering other pages. So it
- needs a multi-pass system. But rendering the whole page in each pass is
- rather obscene.
-
- It would be better to have the first pass be a data gathering pass. Such
- a pass would still need to load and parse the page contents etc, but
- wouldn't need to generate html or write anything to disk.
+* Look at splitting up CGI.pm. But note that too much splitting can slow
+ perl down.
- One problem with this idea is that it could turn into 2x the work in
- cases where ikiwiki currently efficiently renders a page just once. And
- caching between the passes to avoid that wouldn't do good things to the
- memory footprint.
+ > It's split enough, or possibly more than enough, now. :-)
- Might be best to just do a partial first pass, getting eg, the page links
- up-to-date, and then multiple, but generally fewer, rendering passes.
+* 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.
-* 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.
+ > Seems to be O(Num Pages * Num Links in Page), or effectively O(N)
+ > pages for most wikis.
-* Look at splitting up CGI.pm. But note that too much splitting can slow
- perl down.
+[[done]]
projects / ikiwiki.git / blobdiff