Quote:
Originally Posted by chaley
There is no doubt that calibre reads the entire spreadsheet into memory. The question you are raising is whether memory consumed can get large enough to matter.
|
Well, yeah. I wasn't explicit enough in stating that, I believe.
I only did a very rough and sketchy order of magnitude calculation from the size of my metadata.db and the known number of books in the library. I totally forgot, and thus omitted in the calculation, the GUI and other stuff a book needs. Your reasoning makes sense now.
One way to circumvent the memory limitation would be to only load relevant data into RAM and load the other data as needed. However, improvements would vary for certain values of "relevant"- I'm thinking along the lines of only loading title, autor, ID and whatever GUI stuff is needed and only loading the rest as needed on access or search. However, that would increase search times by the number of books times the cost of loading the rest of the metadata to search and would similarly increase the time needed to switch selection from one book to the next, so it would be no real improvement.
A thing that just came into mind is that the OS should shuffle off a certain portion of the DB into swap, if your reasoning is correct. So, wouldn't that imply that there would be a significant delay, if one were to scroll quickly through the library, at a specific point, when the rest of the DB has to be loaded from swap and the beginning dumped into the swap?