[Perf] Occasional hitch when switching pages

[nspitko]

Unsure what causes this one, reporting it to hopefully get more eyes on it and help tracking it down.

I've confirmed this is NOT a server issue, as I can repro this with fully cached images, and have confirmed no server requests were made when the hitch happened.

The exact behavior is fairly simple to repro. Turn off page turn animations, and quickly tab forward/backwards for a while, eventually you'll hit a hitch where it takes a second for the page to advance.

It seems to happen more on larger books/tanks but that might be coincidence/biased dataset. This can be reproed on a fairly small library, I've been doing tests on a sub 100 book set to rule out LRR weirdness.

LRReader 1.9.0.0
LANraragi 0.9.40 (But probably not related, also happens with other backends and not request related)

I've observed this behavior on two different machines, under both windows 10 and 11, if that helps

[Guerra24]

Hello!

I've been unable to replicate this issue... I see a very very small hitch every like 100 pages, but I need to spam the switch page keys to even see it.

From the description, it could be:

1. GC from the in-memory cache. Images and thumbnails are cached in memory first and then in disk.
2. Image decoder lagging. Some of the built-in decoders can be a bit slow with high-res images.

Could you share the resolution and format (png, jpeg, etc.) of the images?

[nspitko]

Ok, GC is a good guess.

Confirmed it happens on: jpg, webp, png. probably not format specific.

I picked jpeg image pairs to test this with, and rapidly switched between them to see the interval behind the hitches

• 1.2mb -> 784mb: 7-9s per hitch.
• 300k -> 290k: 25-30s per hitch.
• 3.2mb -> 3.2mb: 6-7s per hitch.

Hitch length varies, seems worse with larger images. On ~3mb images the hitches are roughly 1s, on a 7950x3d, after which queued keypresses quickly catch up.

[Guerra24]

~3mb images the hitches are roughly 1s, on a 7950x3d

what

Turns out it was GC, but not from my code. It appears that the .net to winrt layer, for some reason, creates a copy of the image to pass it to the native side, a copy that I cannot control in any way so the only way to get rid of it is for the GC to run.

And turns out there is an undocumented but supported way to bypass this extra copy from being created (thanks ms!).

This is the memory without the fix. It creates a lot of copies.

And now with the fix. No more copies.

Even though there are still allocations the main culprit is gone, a very small hitch is still present, but I hope AOT can get rid of it.

My guess why in your case it is very bad would be since that cpu can decode images very fast the GC pause is visible. Another thing is Net Native (the compiler and runtime used in prod builds) which at this point is 10yo tech was not made for this heavily threaded cpus and probably runs GCs not very efficiently.

With my fix and the update to Net 9 should (hopefully) fix this issue completely.