How did kobo write such slow software?

[notzed]

So i'm pretty bamboozled by this.

Currently it takes 25 seconds to close a specific HTML file (a few hundred K, only 5000 odd lines) on the kobo glo - which is a 1Ghz cpu. Attrocious. (and the fact it hard-locks the machine whilst doing it is even worse, haven't they heard of threads?)

The only way I can think is that they did something really dumb like:

array[] all_lines;
while (line = remove_first_element_shifting_the_rest_up(all_line s)) {
free(line);
}

Despite using Java, which is supposedly 'slow' (it isn't, although tbh the arm implementation isn't as efficient as x86), my experiments are:
- faster start up time
- much much more responsive to touches
- never misses finger motions
- quicker rendering
- etc.

Whereas the kobo touch/glo is:
- slow as a wet week in almost every single operation, even pressing a button is slow

After another 12 months I would have expected it to be really amazing - the hardware is really very very competent, and the CPU is many times faster than the eink display can possible keep up with.

It makes their product feel like rubbish, but it's not the hardware's fault.

[sysKin]

Dunno if I agree, without knowing more.

HTML is not split into lines so your example is missing the point. Rendering html is always a difficult process because the only way to see how the text flows is to ask the text rendering engine to render it, even if the result is known to be off-screen. Then, for each line, there's several extra reflows to figure out best hyphenation position, and then you can move to the next line.

I'm not saying there are no optimisations and other tricks, but:
- this is why epub is split into chapters
- modern web browsers also lock up for considerable time reflowing html
- "threads" is not just a label you slap on a program, and in fact on single-core hardware, interruptable code is probably better than multithreaded code

[stewacide]

Indeed. Convert to ePub with calibre which will break tr document down into smaller chunks.

[davidfor]

The Kobo devices do multitask. If you start a WiFi sync, you can keep using the device while that is happening.

Personally, I don't think closing the book and returning to the home page would benefit from multitasking. The delay is probably not in getting rid of the book from memory, but in updating the status of the book, saving bookmarks and annotations and then retrieving the list of books to display. Because they all rely on the database, multitasking or threading might not help. Plus the last step relies on the first being done, so there are some dependencies.

My Glo takes 5 seconds to close a book, which does seem a long time. So, 25 seems excessive. How many books do you have on the device?

[GadgetMan]

Originally Posted by notzed

So i'm pretty bamboozled by this.

Currently it takes 25 seconds to close a specific HTML file (a few hundred K, only 5000 odd lines) on the kobo glo - which is a 1Ghz cpu. Attrocious. (and the fact it hard-locks the machine whilst doing it is even worse, haven't they heard of threads?)

The only way I can think is that they did something really dumb like:

array[] all_lines;
while (line = remove_first_element_shifting_the_rest_up(all_line s)) {
free(line);
}

Despite using Java, which is supposedly 'slow' (it isn't, although tbh the arm implementation isn't as efficient as x86), my experiments are:
- faster start up time
- much much more responsive to touches
- never misses finger motions
- quicker rendering
- etc.

Whereas the kobo touch/glo is:
- slow as a wet week in almost every single operation, even pressing a button is slow

After another 12 months I would have expected it to be really amazing - the hardware is really very very competent, and the CPU is many times faster than the eink display can possible keep up with.

It makes their product feel like rubbish, but it's not the hardware's fault.

I love my Kobo..maybe you should be trying it for what it is designed for.. mine works perfect..just my 3 cents..
DG