Fix lfs_file_rawseek performance issue

[robekras]

This should fix the performance issue if a new seek position belongs to currently cached data.
This avoids unnecessary rereads of file data.

See issue #631

[geky]

Hi @robekras, thanks for putting this optimization together, will bring this in next minor release.

[geky]

Back to performance. As I wrote in issue #631: This change will only fix the case where the new position is after the old/previous position.

Ah sorry, I missed this and taking a second look it looks like there's some issues.

I had assumed CI had passed but it looks like GitHub Actions broke again :/

I'm a bit nervous that this solution make not work in the general case, since we are skipping that file_flush, but CI should quickly determine if that's a problem. I've gone ahead and touched your commit to retrigger CI, sorry if that causes any issues.

---

I think the first bytes of the cached block can contain some other date (block link data?).
This can only be fixed, if we would have an additional variable within the administrative structure which hold the start offset of the real file data?

Hmm, this would be a better way to enable this. In theory you can compute the current block's offset from the position in the file with lfs_ctz_index:

lfs_off_t off = npos;
int index = lfs_ctz_index(lfs, &off);
// off is now the offset in the current block

// index is the block number in the list, but that's not important here

[geky]

Ok apparently GitHub Actions don't run if the PR is not up to date with master. That's... new and annoying...

[robekras]

I think I'm a little been lost now with all the messages here ...

I'm not an expert in working with github, and it would be no problem for me, if I'm not mentioned as contributor.

BTW, the mentioned performance issue is here: #667. I hope it is understandable

[geky]

Hi @robekras, I went ahead and added a commit that implements the full idea outlined in #631 (comment) in 4484165, that is, lfs_file_seek should now avoid flushes when reading and the offset is in the cache.

This mostly involved lfs_ctz_index and some undocumented subtleties of the file structure/cache in order to pass the tests (though I haven't ran the full CI on it yet).

It's worth noting that this optimization only works when reading. When writing a file we always need to flush the cache since we need to make sure we writing out any pending data to disk. Any "holes" created by not-flushing the cache would corrupt the underlying data that we should be merging with our writes.

---

Would you be able to check that this provides the same performance benefit in your application with lvgl?

I know this is functionally correct, thanks to testing, but don't have good performance measurements yet.

[geky]

Thanks for the PR!