Прежде всего, преждевременная оптимизация - корень всего зла. Оптимизируйте что-то только тогда, когда это слишком мало , на практике , и вы определили источник ресурсов (например, с профилированием), и эффект достаточно велик, чтобы стоить усилий и дополнительной сложности (= дополнительная нагрузка на обслуживание в будущем).
Обе реализации zlib.decompress и zlib.decompressobj.decompress находятся в zlibmodule.c, как zlib_decompress_impl и zlib_Decompress_decompress_impl, соответственно.
Они не разделяют код, но их код почти такой же (как и ожидалось) и делегирует те же самые функции библиотеки zlib C.
Так что нет никакой разницы, какую из них использовать в необработанном виде для декомпрессии.
Скорее всего, decompressobj будет иметь крошечные издержки с дополнительной логикой и повторными вызовами Python - но если данные большие, время распаковки превзойдет их.
- То есть, стоит ли замена
decompress на decompressobj (или будет иметь какой-либо эффект), зависит от того, является ли узкое место в каждом конкретном случае памятью, процессором или вводом-выводом (положительный эффект) если память, отрицательный эффект, если процессор, нет эффекта, если ввод / вывод). (Таким образом, перейдите к первому абзацу для руководства.)