Итак, я сделал большой zip-файл с произвольной выборкой:
$ ls -l *zip
-rw-r--r-- 1 aleax 5000 115749854 Nov 18 19:16 large.zip
$ unzip -l large.zip | wc
23396 93633 2254735
, т. Е. 116 МБ с файлами 23,4 КБ и временем:
$ time unzip -d /tmp large.zip >/dev/null
real 0m14.702s
user 0m2.586s
sys 0m5.408s
это предоставляемый системой двоичный файл для распаковки командной строки - без сомнения, настолько точно настроенный и оптимизированный, насколько может быть выполнен чистый C-файл. Затем (после очистки /tmp;-)...:
$ time py26 -c'from zipfile import ZipFile; z=ZipFile("large.zip"); z.extractall("/tmp")'
real 0m13.274s
user 0m5.059s
sys 0m5.166s
... а это Python со своей стандартной библиотекой - немного более требовательным к процессору, но более чем на 10% быстрее в реальном времени, то есть по истечении времени.
Конечно, вы можете повторить такие измерения (на вашей конкретной платформе - если она не загружена ЦП, например, медленная микросхема ARM, то дополнительные требования процессора Python к времени ЦП могут в конечном итоге замедлить его - и ваши конкретные Интересны zip-файлы, так как каждый большой zip-файл будет иметь разную смесь и, возможно, производительность). Но это наводит меня на мысль, что не так много места для создания расширения Python намного быстрее, чем старый добрый zipfile - так как его использование в Python превосходит разархивирование с включенным системным чистым C! -)