Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking intermediate buffer sizes (in ZEP 2 or otherwise) #278

Open
jakirkham opened this issue Nov 1, 2023 · 2 comments
Open

Tracking intermediate buffer sizes (in ZEP 2 or otherwise) #278

jakirkham opened this issue Nov 1, 2023 · 2 comments

Comments

@jakirkham
Copy link
Member

Currently if a pipeline of codecs is used, it would be useful to track the intermediate sizes of the buffers as they are transformed so that enough scratch space can be allocated to decode data efficiently

@jbms
Copy link
Contributor

jbms commented Nov 1, 2023

When it can be determined independent of the data, just based on e.g. shapes, implementations can already (and do already) do this. Some compression codecs also store the decoded size. In general, though, it might be necessary to store an additional size field along with the encoded data. Is that what you are proposing?

@jakirkham
Copy link
Member Author

Indeed for the case of a single codec, this is unneeded

Think it comes up in cases when codecs are chained. For example using run-length encoding or bit packing followed by another compressor. It would be helpful to know what size the buffer between those steps is for decoding so as to allocate for it appropriately

Yeah this is what I'm thinking

It's possible the exact size of any intermediate buffers is not strictly necessary, but instead some largest intermediate buffer seen may be good enough. In this way it might be similar to Python's __length_hint__

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants