git.oblomov.eu Git - ikiwiki/blob - doc/forum/speeding_up_ikiwiki.mdwn

   1 My website takes a fairly long time to render. It takes a long time to do
   2 things like add pages, too. I'd like to try and understand what takes the
   3 time and what I might be able to do to speed things up.
   4
   5 I have 1,234 objects on my site (yikes!). 717 are items under "/log" which
   6 I think might be the main culprit because there are some complex pagespecs
   7 operating in that area (e.g. log/YYYY/MM/DD, YYYY/MM and YYYY for YYYY >=
   8 2003, YYYY <= 2008 which include every page under log/ which was modified
   9 in the corresponding YYYY or YYYY/MM or YYYY/MM/DD). There is very little
  10 linking between the world outside of /log and that within it.
  11
  12 I was interested in generating a graphical representation of ikiwiki's idea of
  13 page inter-dependencies. I started by looking at the '%links' hash using the
  14 following plugin:
  15
  16     #!/usr/bin/perl
  17     package IkiWiki::Plugin::deps;
  18
  19     use warnings;
  20     use strict;
  21     use IkiWiki 3.00;
  22
  23
  24     sub import {
  25         hook(type => "format", id => "deps", call => \&fooble);
  26     }
  27
  28     my $hasrun = 0;
  29
  30     sub fooble ($$) {
  31         if(0 == $hasrun) {
  32             $hasrun = 1;
  33             open MYFILE, ">/home/jon/deps.dot";
  34             foreach my $key (keys %links) {
  35                 my $arrref = $links{$key};
  36                 foreach my $page (@$arrref) {
  37                     print MYFILE "$key -> $page;\n";
  38                 }
  39             }
  40             close MYFILE;
  41         }
  42     }
  43
  44     1
  45
  46 The resulting file was enormous: 2,734! This turns out to be because of the following code in scan() in Render.pm:
  47
  48     if ($config{discussion}) {$
  49         # Discussion links are a special case since they're
  50         # not in the text of the page, but on its template.
  51         $links{$page}=[ $page."/".gettext("discussion") ];
  52
  53 Worst case (no existing discussion pages) this will double the number of link
  54 relationships. Filtering out all of those, the output drops to 1,657. This
  55 number is still too large to really visualize: the graphviz PNG and PDF output
  56 engines segfault for me, the PS one works but I can't get any PS software to
  57 render it without exploding.
  58
  59 Now, the relations in the links hash are not the same thing as Ikiwiki's notion of dependencies. Can anyone point me at  that data structure / where I might be able to add some debugging foo to generate a graph of it?
  60
  61 Once I've figured out that I might be able to optimize some pagespecs. I
  62 understand pagespecs are essentially translated into sequential perl code. I
  63 might gain some speed if I structure my complex pagespecs so that the tests
  64 which have the best time complexity vs. "pages ruled out" ratio are performed
  65 first.
  66
  67 I might also be able to find some dependencies which shouldn't be there and
  68 remove the dependency.
  69
  70 In general any advice people could offer on profiling ikiwiki would be great.
  71 I did wonder about invoking the magic profiling arguments to perl via the CGI
  72 wrapper.
  73
  74
  75 -- [[Jon]]
  76
  77 > Dependencies go in the `%IkiWiki::depends` hash, which is not exported. It
  78 > can also be dumped out as part of the wiki state - see [[tips/inside_dot_ikiwiki]].
  79 >
  80 > Nowadays, it's a hash of pagespecs, and there
  81 > is also a `IkiWiki::depends_simple` hash of simple page names.
  82 >
  83 > I've been hoping to speed up IkiWiki too - making a lot of photo albums
  84 > with my [[plugins/contrib/album]] plugin makes it pretty slow.
  85 >
  86 > One thing that I found was a big improvement was to use `quick=yes` on all
  87 > my `archive=yes` [[ikiwiki/directive/inline]]s. --[[smcv]]
  88
  89 > Take a look at [[tips/optimising_ikiwiki]] for lots of helpful advice.
  90 > --[[Joey]]