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).
I don't know if there's any size that's not going to make me nervous, frankly. Ideally the cache should be as small as possible without losing the performance gain.
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'd honestly be surprised if the read size is ever going to be that large in practice. Despite that I don't have a strong opinion, but if you need one I'd say to just always use the cache. It'd be easy to add a direct path later anyway.
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.
Yes, I meant the other way around, sorry.
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...
Yes, you're right, sorry.