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
Pako is pretty fat and slow. There's also fflate, which is faster and more lightweight, but migrating to that doesn't make much sense now that a native solution is available. Maybe compression streams could be used by default with fallback to pako (at least for now) ?
Context: I was experimenting with tabix & gff-js and there seems to be several optimization opportunities. However, this would probably the most straightforward one, assuming that the native decompression stream is at least as performant as fflate is.
The text was updated successfully, but these errors were encountered:
(note that we have built up some maybe awkward stuff around creating virtual file offsets based ids based on the pako code over time, but we could maybe make new workarounds based on decompression stream also)
(De)compression streams are now supported in all web browsers: https://developer.mozilla.org/en-US/docs/Web/API/DecompressionStream
Pako is pretty fat and slow. There's also fflate, which is faster and more lightweight, but migrating to that doesn't make much sense now that a native solution is available. Maybe compression streams could be used by default with fallback to pako (at least for now) ?
Context: I was experimenting with tabix & gff-js and there seems to be several optimization opportunities. However, this would probably the most straightforward one, assuming that the native decompression stream is at least as performant as fflate is.
The text was updated successfully, but these errors were encountered: