This will take up up to 32 MiB per wg_parser
I looked up online about what chunk size reads on an SSD are, and found the number 512kb. Setting the chunk to this size seems to actually _improve_ the performance, presumably because we're spending less time reading/copying data we don't need at the moment. Do you think this is small enough (512kb per chunk * 4 chunks = 2mb per parser).
"why are read_parser_cache() and load_parser_cache() separate functions?
Ack, I'll put these together.
And along similar lines, is it even worth falling back to the old path for larger read requests?
The advantage to falling back that I can think of is that it's one less copy, as the data is first copied into the cache only to be read out to the buffer afterwards. How important this is to performance probably depends on how often we hit the read_size > chunk_size path. In my test case, I don't think it would hurt too much, but in the case where GStreamer reads the whole file at once, maybe this would make things worse. If it's okay I'll let you make the judgement call.
I think it would be simpler just to make the index itself be the rank
Ack
If not, we should factor out a helper to actually perform the read pseudo-callback.
I'm a bit confused here, if it's not worth it to fall back to the old path, then we'd only have one area performing the read pseudo callback, the function reading/loading from the cache into the buffer, right? If you meant the other way around, where we keep both paths then yeah, I can make that helper.
I'd propose "input_cache" or "read_cache" here.
Ack
The parser mutex doesn't seem to be taken around everything that it should be.
I'm pretty sure getrange doesn't need to be implemented as thread-safe, as GStreamer takes a lock to the pad anyway before invoking the callback:
https://github.com/GStreamer/gstreamer/blob/2db3ddaa9d8e9e0a1659d7e48623c512...