Quote:
Originally Posted by TechniSol
I'm curious. I don't have a bazillion ebooks, so am asking those who have a pile of them on their readers. I have only around 234 titles on my Glo, with some distributed over 11 shelves. But some are a bit ponderous, the one I'm making my way through now has 4,443 pages according to the reader. Anyhow, I'm not noticing anything out of the ordinary -other than it taking a few seconds to open this huge book from the home page carrousel, but wondered what is causing the problem with larger collections.
Is it because of cover image processing? Do you see a major difference in performance when looking at the shelves view with small icons vs. the larger covers without the text? (Wrench option menu on individual shelves and the books choice in the Library)
Is it because there are in some cases several thousand entries in the database to be processed? Is it because they make sure all the cover images are rendered before displaying the first page of items on a shelf or in the Library? Perhaps code that only prepared the covers for a page or so in advance would limit the initial lag time and allow for further processing as pages were advanced. This, of course, assumes they have multi-threaded or multi-tasking capability so a background task could continue to process items while pages of shelves or the Library are advanced, or that short waits beat one really long wait?
If it's sorting the database, why don't they include index fields for their different sorts as a series of linked lists and just re-sort the index, really just insert or delete, as titles are added or deleted?
I'm just trying to get a handle on why it slows down with so many books beyond what seems proportionate for the number of books. I mean a 1GHz processor is a lot of oomph all in all.
Or is it really not the code so much as processing problems with certain books?
|
I can't speak as one who has thousands on their reader, BUT the thing that DID make a difference for me, was a) putting all my epubs on an external SD card and b) using calibre to send covers right from a blank slate.
I never sent over hundreds to be processed by the glo at once, but every batch (between 5 and 20 epubs i would guess) i checked that the covers were correctly created...after doing that there is no sign of the covers being created when i open books or shelves and there is no longer any lag. I only have about 400 or so books and 3 pages of shelves, but at least one of my shelves has 100 books on it. I only use the shelves as really general divisions...like british classics, contemporary american lit., etc. I use series info, but don't create shelves for series, and for me that is enough organisation.
The reason I bring my case up though, is that I orginally didn't have "create covers" in calibre checked. then i did. so only some were sent to the glo before the kobo had a chance to create them. but the covers that the kobo supposedly had already created, would seem to recreate every time. on the main memory. and lag EVERYTHING.
I felt like what might have made the big difference for my case was that when i took all my epubs/pdfs off my main memory and put them on a storage card, that the storage card started fresh and only had book related info on it. i really don't know if this is the reason, but when i looked at all the images saved on the internal memory...well there are something like 5000. it's like every time i had recommended books come at me, those were saved, everytime i searched in the kobo store, those were saved, etc, etc, etc. insane. but some other images that might be important...so i haven't just gone and deleted them all.
whereas my external drive has exactly 3x#of books on card.
maybe this is totally unrelated, and by the time I get up to 2000 books mine will be crap as well, but since i saw such an improvement doing it this way, when in the past the lag was quite bad, i felt there just might be something that would spark an idea in someone's brain!