Comment 4 for bug 1396787

I've hit the same bug and did some investigation. I profiled the unattended-upgrade script with python's cProfile and attached the result.

I've run:
sudo python3 -m cProfile -s time /usr/bin/unattended-upgrade -d -v
on Ubuntu 16.04.3 booted from live cd after uncommenting the "${distro_id}:${distro_codename}-security"; line in /etc/apt/apt.conf.d/50unattended-upgrades. Otherwise no packages are selected for an upgrade and the issue doesn't reproduce.

It turns out that several functions in apt's cache are called millions of times. I tracked it down to the quadratic nature of the algorithm, which appears to come from the very initial version of the script:
https://github.com/mvo5/unattended-upgrades/blob/0ec001874ad48300199565f8591818ca75bc5f9f/unattended.py#L47

The check_changes_for_sanity() function loops over all packages in the cache. This function is called for every package marked for upgrade.

The problem appears on systems with many packages to upgrade (in my case it was 169). It makes the initial unattended-upgrades run ridiculously slow. Also, on systems configured to only perform security updates, but not other updates there's always a considerable list of packages to upgrade. It renders unattended-upgrades almost unusable on such systems.

I think this is a serious issue and the algorithm should be overhauled. Doing so many checks seems unnecessary.