doc/todo/multi-thread_ikiwiki.mdwn

   1 [[!tag wishlist]]
   2
   3 [My ikiwiki instance](http://www.ipol.im/) is quite heavy. 674M of data in the source repo, 1.1G in its .git folder.
   4 Lots of \[[!img ]] (~2200), lots of \[[!teximg ]] (~2700). A complete rebuild takes 10 minutes.
   5
   6 We could use a big machine, with plenty of CPUs. Could some multi-threading support be added to ikiwiki, by forking out all the external heavy  plugins (imagemagick, tex, ...) and/or by processing pages in parallel?
   7
   8 Disclaimer: I know nothing of the Perl approach to parallel processing.
   9
  10 > I agree that it would be lovely to be able to use multiple processors to speed up rebuilds on big sites (I have a big site myself), but, taking a quick look at what Perl threads entails, and taking into acount what I've seen of the code of IkiWiki, it would take a massive rewrite to make IkiWiki thread-safe - the API would have to be completely rewritten - and then more work again to introduce threading itself.  So my unofficial humble opinion is that it's unlikely to be done.
  11 > Which is a pity, and I hope I'm mistaken about it.
  12 > --[[KathrynAndersen]]
  13
  14 > > I have much less experience with the internals of Ikiwiki, much
  15 > > less Multi-threading perl, but I agree that to make Ikiwiki thread
  16 > > safe and to make the modifications to really take advantage of the
  17 > > threads is probably beyond the realm of reasonable
  18 > > expectations. Having said that, I wonder if there aren't ways to
  19 > > make Ikiwiki perform better for these big cases where the only
  20 > > option is to wait for it to grind through everything. Something
  21 > > along the lines of doing all of the aggregation and dependency
  22 > > heavy stuff early on, and then doing all of the page rendering
  23 > > stuff at the end quasi-asynchronously? Or am I way off in the deep
  24 > > end.
  25 > >
  26 > > From a practical perspective, it seems like these massive rebuild
  27 > > situations represent a really small subset of ikiwiki builds. Most
  28 > > sites are pretty small, and most sites need full rebuilds very
  29 > > very infrequently. In that scope, 10 minute rebuilds aren't that
  30 > > bad seeming. In terms of performance challenges, it's the one page
  31 > > with 3-5 dependency that takes 10 seconds (say) to rebuild that's
  32 > > a larger challenge for Ikiwiki as a whole. At the same time, I'd
  33 > > be willing to bet that performance benefits for these really big
  34 > > repositories for using fast disks (i.e. SSDs) could probably just
  35 > > about meet the benefit of most of the threading/async work.
  36 > >
  37 > > --[[tychoish]]