View Single Post
Old 04-14-2016, 08:10 AM   #471
NullNix
Guru
NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.NullNix ought to be getting tired of karma fortunes by now.
 
Posts: 929
Karma: 15576314
Join Date: Jan 2013
Location: Ely, Cambridgeshire, UK
Device: Kindle Oasis 3, Kindle Oasis 1
Quote:
Originally Posted by Jason90 View Post
I might be imagining this but it seems to change pages and open books faster??

Might be the fact he's just pressing a button instead of tapping the screen to flip pages.
It's also that this is almost certainly a recently-booted and nearly empty device (being new and all). Nearly empty means the indexer and anything else that has to traverse all books has less load (and if any of these are using O(n^2) algorithms, which I hope they're not, that could be very significant) and that any data structures that involve all books use less memory. The indexes are mmap()ed at need, but even so having to mmap() a significant fraction of the memory capacity of the machine may sometimes force otherwise-useful pages out of memory.

The recently-booted means that the various heaps for the individual binaries are not fragmented. Over time the heap for long-running binaries will get more and more fragmented, at asymptotically slower rates, and eventually allocation requests will start to fail and you'll get that restart-your-Kindle notice: but long before then noticeable slowdowns will result from worse dcache utilization for small allocations (large allocations are not affected by that particular sub-problem because they're bigger than a cacheline and often bigger than a page: we're talking 64 bytes and less here: but nearly all allocations are small ones).

This is not Kindle-specific: every present-day device bigger than a DSP has both problems. It would be nice to avoid the heap fragmentation problem entirely, but it would mean rewriting more or less everything in a language that does not expose raw pointers so it could freely migrate things around the heap at any time, i.e., not C (not even Rust, unless you constrained nearly all the system to be in a subset that did not have access to raw pointers). It's more practical to rewrite things to consist of larger numbers of smaller processes, only the Kindle has more or less already *done* that. I don't see what else they can do to solve this ongoing minor reboot-every-couple-of-months annoyance which doesn't involve rewriting the world.
NullNix is offline   Reply With Quote