KOReader is blazing fast

[BloodRagg]

Thank you guys for making such an awesome product

It boots really fast: https://streamable.com/2tf4y

I am glad it's working for you. And yes, I love the KOReader app (for Kobo) as well, and thanks to the devs for all their work on it.

That said...just an observation, but speed has NOT been one of the strengths of KOReader since I've been using it. Quite the contrary really; I've found it to be frustratingly slow when opening larger books (but it does ok on books of more common sizes, so this is not an issue with most books). I'm referring to how quickly it can load a book, or process a book-wide change (like a font change). These tasks, along with searching a book's contents, are the most common things I do that test an app's speed.

Here's a case in point: I have some books in my collection that are quite large, and quite complex in that they contain a lot of internal links. For example, one of these is the complete works of Shakespeare, an annotated edition that has many thousands of internal links (for all the footnotes). For a first-time (uncached) load of this book, KOReader took over 12 minutes. Even after it was cached, it would still take over 2 minutes just to open the book. Any any time you made a change to the reading settings like font, etc., it also takes several minutes to update the book. In contrast, the Kobo shipped software could do a first time load in under 20 seconds, and subsequent/cached loads only take 2-3 seconds. Similar with font/style changes.

I don't see this as a Pri 1 urgent issue (because it's a non-issue with most books). But hopefully KOReader can eventually improve its performance at processing large, complex texts. It's a use case that will matter to some readers, and some types of content.

[Frenzie]

That said...just an observation, but speed has NOT been one of the strengths of KOReader since I've been using it. Quite the contrary really; I've found it to be frustratingly slow when opening larger books (but it does ok on books of more common sizes, so this is not an issue with most books).

It's not really a book size but a number of nodes problem. You could create a relatively small book that'd bring crengine to its knees.

Nickel could be faster at parsing an EPUB, but I would suspect that Nickel is primarily a bit more clever about what it actually does when loading a book. Since an EPUB is normally divided into multiple XHTML files, you shouldn't need to render more than one or two at once. (The downside being you wouldn't have reliable page numbers/percentages.)

In PDF/DjVu this works out better in KOReader. The current page is shown, while the next page is rendered into memory.

These tasks, along with searching a book's contents, are the most common things I do that test an app's speed.

That's a very narrow definition of speed.

Originally Posted by Frenzie

That's a very narrow definition of speed.

Of course. And yet you'd admit that opening a book is something everybody has to do, so if it takes 10 minutes on first open, or 2-3 minutes when cached, I think a lot of folks would find that kind of a no-go.

I'm not running down KOReader--I love it. I use it for a lot of things, just not really large books.

[NiLuJe]

Strangely enough, that may be the *one* thing where I don't really care about performance that much. Mainly because ePub is a terrible format if you want something speedy to begin with anyway...

[Frenzie]

Originally Posted by maximus83

And yet you'd admit that opening a book is something everybody has to do, so if it takes 10 minutes on first open, or 2-3 minutes when cached, I think a lot of folks would find that kind of a no-go.

Of course it is, and if this EPUB is something freely available I'll gladly do some profiling with it. Although like I said, any real improvements can only come from being smarter and not rendering the whole file on load. Because even increasing performance tenfold would still give you a good minute. And that's highly unlikely unless there's something particular that could be easily cached. But I think we're fairly close to the useful limits on that one.

Side question, have you tested how fast Plato is on your document? In theory it should be very fast because it does exactly what I described. I suspect it should not only feel much faster than Nickel, but also be faster in the artificial stress test.

(Another side question, did you long-press on the file in KOReader and open in MuPDF? I expect that should also take 10-20 minutes, mind you, but you never know.)

Originally Posted by NiLuJe

Strangely enough, that may be the *one* thing where I don't really care about performance that much. Mainly because ePub is a terrible format if you want something speedy to begin with anyway...

I gladly triple the loading times for proper kerning & ligatures. In fact I've been finding myself actually reading EPUBs since that was added, which I almost never used to. Of course we're talking only a couple of seconds here, taking loading times from <1 second to something somewhat more perceptible but fast enough.

Originally Posted by Frenzie

Of course it is, and if this EPUB is something freely available I'll gladly do some profiling with it.

Sorry, the two best test-case books I'm using are linked below, but are not freely available. What they have in common is large size, and thousands of internal links due to tons of foot/end notes, and tons of separate chunks of text--basically 'text nodes' from a program's point of view. If one could something similar in the public domain, that would probably be the ideal testing book. All I know is that when I open these same files in the big bookstore apps, they load so much quicker it's a non-issue. However, my workaround is: this doesn't matter all that much. I just don't bother opening the small handful of books I have like this in KOReader, it handles everything else beautifully so it's a low % case.

https://www.kobo.com/us/en/ebook/epub-esv-study-bible
https://www.kobo.com/us/en/ebook/wil...complete-works

Originally Posted by Frenzie

Side question, have you tested how fast Plato is on your document? In theory it should be very fast because it does exactly what I described. I suspect it should not only feel much faster than Nickel, but also be faster in the artificial stress test.

I have not, maybe it's time to do that.

Originally Posted by Frenzie

(Another side question, did you long-press on the file in KOReader and open in MuPDF? I expect that should also take 10-20 minutes, mind you, but you never know.)

I did not--but these docs are epub not PDF? The PDF reader in KOReader itself works fine for me, in fact it's awesome.

[Frenzie]

MuPDF can also read EPUB and FB2 files. I added some preliminary basic support for that on KOReader's side here. I did so mostly in the hope that someone else would flesh it out further — beginnings are always the hardest after all. Unfortunately that hasn't happened.

Here's the full list of filetypes MuPDF can open.

Sweet, thanks to you and NiLuJe and anybody else who has worked on KOReader, it's a great app. Man it saved me with its PDF handling, I had a computer science free textbook in PDF that was rendering way too small almost unreadable in KOBO. With KOReader, it has a lot more settings for fine tuning PDFs, and I was able to get it to a point that the PDF just comfortably filled the screen and was readable, and the Python code samples would lay out nicely even in portrait mode.

[Frenzie]

As an aside, few people know this since it's a bit hidden, but while in page flipping mode (top left corner) you can double tap to zoom in on a piece of the page.

I almost never use it. I just use zoom to fit page or content. But the proof of concept should still be taken to the main view someday.

[heyman]

Originally Posted by Frenzie

Nickel could be faster at parsing an EPUB

Koreader should have faster page turning on Kobo right? In normal reading

[Frenzie]

I said could, not is. I've got an EPUB here of the larger persuasion that takes ~10 s to load in Nickel and ~5-6 s in KOReader/crengine, which is the general trend in my experience.

But indeed, Nickel is surprisingly slow to turn pages. It seems to take a small eternity, although tbh I hadn't really noticed in normal use. I wonder if maybe it's an artificial delay, e.g. to support double taps, to prevent accidental double page turns, or to avoid potentially ugly looking overlapping refreshes?

[NiLuJe]

The ePub renderer is mightily awful as far as performance goes, especially on older FW versions.

The KePub renderer, on the other hand, has always been pretty decent, although still a tiny bit slower than a Kindle, which is especially noticeable if you've recently used one. Still perfectly usable, though (unlike the ePub renderer, IMHO, which was probably colored by the fact that I did come from a Kindle ;p).

With the recent tweaks (i.e., >= 2019.05), in KOReader, as long as you're staying in the default Portrait orientation, we're pretty much trouncing everything out there in terms of page turn speed, though, especially if you have a device with physical buttons, because you bypass a good chunk of the input loop/gesture detection/delay thingy that way.

Sidebar: turns out storage performance is also pretty key to some specific use-cases. For instance, I'd always found dictionary performance to be pretty meh on my H2O, while it's basically instant on my Forma.

The difference? A real eMMC chip on the Forma vs. the insane internal SD card design on the H2O. It's sure nice on the hackability front, but, man, is it awful in terms of performance.

[Frenzie]

Touch/gesture detection generally doesn't really delay, unless there are a lot of links in the document or on the page. (In which case technically it's link detection that delays, not gesture detection.)

Since Nickel easily takes 10 times as long to turn a page if not more, I guess that means Nickel would also be significantly worse for battery life?

[NiLuJe]

Yup! There's probably a mainly fairly psychological effect of the button feeling clicky and stuff showing up on screen straight away that just feels nicer ;p.

Note that the H2O is a fairly terrible benchmark, because it has weird-ass power management quirks that make its frequency scaling behave pretty erratically. Meaning it can be hard to actually get it to stick to the full clock speed properly. It tends to get stuck at lower clock speeds for far too long for no good reason.

For instance, mine is fairly consistent on a fresh, cold boot, and then starts to go wonky at the first sleep cycle. Although, "fairly consistent" might be stretching it, because it tends to stick the other way around after a cold boot (meaning stick to the highest clock speed even when idle).