Bug#492086: partman optimisations

[Colin Watson <cjwatson@debian.org>]

severity 256237 wishlist
merge 256237 492086
thanks

I did a fair bit of work on this recently.  It was in the context of
Ubuntu's graphical installer
(https://wiki.ubuntu.com/Ubiquity/PartitionerOptimisation), but the bulk
of the optimisations applied to partman proper as well; it was much
easier to profile this in the context of ubiquity anyway because it
performs many partman operations behind the scenes, so some of the times
are longer and less susceptible to random variation.

In particular, I applied the following improvements, which should have
provided order-of-magnitude speed-ups to most partman user interface
operations, cutting out around 90% of the time spent in the inner loop:

partman-base (136) unstable; urgency=low

  [ Colin Watson ]
[...]
  * Merge from Ubuntu:
    - Call sed outside debconf_select's inner loop. In my benchmarks using
      two disks with eight partitions each, this reduces debconf_select's
      runtime on partman/choose_partition from 0.69 seconds to 0.07 seconds.
    - Cache the output of partition_tree_choices for each disk, invalidating
      the cache whenever we update a partition on the disk. In the above
      benchmark, this saves on the order of half a second every time we
      redisplay the partition tree when nothing has changed (e.g. on backing
      up from a partition).
[...]

 -- Christian Perrier <bubulle@debian.org>  Wed, 06 Jan 2010 22:38:01 +0100

(And then a regression fix in partman-base 137, uploaded 14 Jan 2010.)

Most of my use of partman is in virtual machines, which may not exhibit
quite the same timing characteristics as on real hardware, but I think
this should have made a very substantial difference and subjectively it
does feel more responsive now.  Marga, John, it would be great if you
could try out a current daily build and report whether this satisfies
your concerns.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]