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 think this idea is good generally. The main constraint is that to make use of the message index, you need to decompress the whole chunk first. But if you don't care about the message index and you're just doing a linear file read, then streaming decompression of chunks is what you want for sure. We support this in the go library but none of the others afaik.
I think the main place where you benefit from this is when reading a lot of mcap files at once (for instance, merging them together). OOMs during reading of a single MCAP file may also be addressed, but not if they are caused by oversized individual messages, which is the most common reason for oversized chunks in my experience. Absent massive messages, if the writer is configured with a sane chunk size then OOMs should not generally be encountered when reading a single file -- the default decompressed chunk sizes are in the single-digit megabytes, and you generally only need one at a time open.
So to summarize, I think the feature is good but it would be worth checking if there's anything odd going on with your chunking, if the context here is reading single files. You can do this with
mcap info file.mcap
and
mcap list chunks file.mcap
which will show all the individual sizes. There was an old bug in the rust writer that resulted in single-chunk files. I'm curious if you may be on an old version of the rust writer that still has this behavior: #777
In the Python mcap reader API, chunks are read into memory as full blocks. This often causes OOM errors on smaller systems.
Main reader loop:
mcap/python/mcap/mcap/reader.py
Lines 294 to 318 in a68c769
Chunk data read line:
mcap/python/mcap/mcap/records.py
Line 173 in 0a06331
The text was updated successfully, but these errors were encountered: