View Single Post
Old 06-22-2011, 08:25 PM   #13
Iņigo
Guru
Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.
 
Posts: 710
Karma: 72743
Join Date: Feb 2008
Location: Here or there
Device: iRex iLiad, in love with iRex DR800S. Also a K4NT. Now a Kobo Aura
Not directly related with the core of this thread, but as I can't remember now where I mention, I'll comment here.

I have over 4k books on my DR800, global db is ~28.5 MB.
Some time ago mdbindex stopped adding automatically new covers to the DB.
Books view spends over 30 secs to show the files the first time, 20 secs next ones.
Recently Added view takes ~9 secs with 15 files, the same with 50 files, 7 secs next times.
I also noted that it looks like the device enters in suspend mode when waiting much time for showing the books if no screen activity is produced, so I have to wake it pressing menu key.

Today I've did some new tests removing global.db and rebuilding without images.
global.db is less than 2 MB.
Books view spends no more than 2 or 3 secs to show the files.
Similar time for Recently Added view.


These are some of my conclusions:
- main culprit of the slowness is the quantify of images in the DB
- when indexing with covers there is a moment where mdbindex stops working. I've tested removing the files the indexer was analyzing at that moment but it's the same. So I presume the problem is the lack of free memory. Would enabling a swap partition/file improve something?
- does DR DB engine cache some contents in memory?


A good but infeasible solution would be to use 2 different db files, one for metadata and another one for images.
Or better, not using a db for images, but a hidden directory with the cover files: System/_covers/medium/id.png, System/_covers/small/id.png.
This solution doesn't seem difficult. I'll study it.
- change code to avoid writing images to the DB when closing UDS, and write to a file
- CTB would only load the covers needed for current page

This would reduce the overall DB size in memory and the introduced slowness due to images file loading should not be noticeable...

Iņigo

Last edited by Iņigo; 06-22-2011 at 08:45 PM.
Iņigo is offline   Reply With Quote