You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in adapting zune-inflate for my purposes: concatenating multiple deflated pieces of data into a single buffer (imagine a zip file that has several files that can should be seen as one)
Right now, zune-inflate will issue a new buffer per request that then needs to be copied to the concatenated buffer.
Do you see a future where zune-inflate writes to a provided buffer? I can provide a buffer that has the required space + necessary padding.
For context, I'm in an environment where memory allocations are slower (Wasm), so I'm interested in avoiding them where possible.
EDIT: removed irrelevant discussion if provided API is implemented.
The text was updated successfully, but these errors were encountered:
Hi, yes, I do strive to provide an api that can writes to a pre-allocated buffer, but the problem is with inflate, we can't know how much space is needed to fully decompress given compressed data as the format doesn't have a size field or anything like that , unless you frame your data and explicitly provide size.
The alternative is that we always check if we can write to a provided buffer and if not we signal an error but suspension and recoverability complicates the api a lot so I'm not sure that's a worthwhile road to follow, but open to ideas
I'm interested in adapting zune-inflate for my purposes: concatenating multiple deflated pieces of data into a single buffer (imagine a zip file that has several files that can should be seen as one)
Right now, zune-inflate will issue a new buffer per request that then needs to be copied to the concatenated buffer.
Do you see a future where zune-inflate writes to a provided buffer? I can provide a buffer that has the required space + necessary padding.
For context, I'm in an environment where memory allocations are slower (Wasm), so I'm interested in avoiding them where possible.
EDIT: removed irrelevant discussion if provided API is implemented.
The text was updated successfully, but these errors were encountered: