Skip to content

Conversation

@cmaloney
Copy link
Contributor

@cmaloney cmaloney commented Dec 3, 2025

Removes a copy going from bytearray to bytes.

Removes a copy going from bytearray to bytes.
@cmaloney cmaloney changed the title gh-141968: Use take_byes in zipfile._ZipDecrypter gh-141968: Use take_bytes in zipfile._ZipDecrypter Dec 15, 2025
@cmaloney
Copy link
Contributor Author

@serhiy-storchaka would you be up for taking a look at this?

@serhiy-storchaka
Copy link
Member

Does it cause a measurable difference?

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think this has a measurable effect, but at least it does not make it worse.

@cmaloney
Copy link
Contributor Author

cmaloney commented Jan 8, 2026

Keep hunting for a zipfile to test with that's 1KB or larger and encrypted this way but haven't found one / not a commonly used thing in the infra I'm familiar with.

In theory the amount of time saved is proportional to the memcpy time on most platforms. The core interpreter loop in my measuring is fast for most these I've done and the perf delta ends up being 5-10%...

This particular one there is some argument we could pattern recognize at the JIT level: If a bytearray is uniquely referenced in a call to bytes in a return (a point where no further references could be created) then can take the buffer / convert to a .take_bytes(). That seems a long ways off and this still wouldn't pessimize / is expressing intent "the result bytearray is no longer owning this storage)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants