Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

zipfile.Path.open is slow when opening for writing in a ZIP with many entries #126565

Closed
Labels
3.12only security fixes3.13bugs and security fixes3.14bugs and security fixesperformancePerformance or resource usagestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error
@janhicken

Description

@janhicken

Bug report

Bug description:

I'm using thezipfile module to create a ZIP file with thousands of members. Each file is created by creating a correspondingzipfile.Path object first and then calling.open() on it.

The implementation ofopen() contains a check whether the file already exists when opening a file in read mode:

ifnotself.exists()andzip_mode=='r':raiseFileNotFoundError(self)

However,self.exists() is called even in write mode, because it is theand operator's first argument.
The call toself.exists() is quite slow however, because this requires the ZIP file's.namelist() to be computed, which in turn requires to compute all the implied directories. After all, this is the reason why theFastLookup optimization exists for ZIP files in read mode.

I found this issue after profiling my application and was surprised that more than half of its execution time was spent in computing implied ZIP directories.

I would propose to swap theand arguments so the check looks like this:

ifzip_mode=="r"andnotself.exists():raiseFileNotFoundError(self)

This will cause theself.exists() check to only be run in read mode, where the check is fast because ofFastLookup anyway.

I'm happy to provide a pull request with this change.

CPython versions tested on:

3.11, 3.12

Operating systems tested on:

Linux, macOS

Linked PRs

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.12only security fixes3.13bugs and security fixes3.14bugs and security fixesperformancePerformance or resource usagestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp