Thumbnail Cache - Time to display
Moderators: XnTriq, helmut, xnview
Now the Cache panel is usable (ie: number&filesize computed in the background).
But I still see major issues with the DB:
- If I remove a folder with just 1 image in my 2GB cache, XnView will need to write/recompute a whole 2GB temporary file to remove that 5KB thumbnail...
- XnView is still reading 20 times each segment of the DB, which I believe has severe performance hit.
Here is a screenshot of this with FileMon when entering a folder with 3 thumbnails -> each needed segment of the DB will be read about 20 times (just 2 identical segments are highlighted here, but it continues for pages and pages like this). Also notice the "db-journal" systematic error in-between.
But I still see major issues with the DB:
- If I remove a folder with just 1 image in my 2GB cache, XnView will need to write/recompute a whole 2GB temporary file to remove that 5KB thumbnail...
- XnView is still reading 20 times each segment of the DB, which I believe has severe performance hit.
Here is a screenshot of this with FileMon when entering a folder with 3 thumbnails -> each needed segment of the DB will be read about 20 times (just 2 identical segments are highlighted here, but it continues for pages and pages like this). Also notice the "db-journal" systematic error in-between.
Olivier
Here it's the SQL DB command, not meOlivier_G wrote:Now the Cache panel is usable (ie: number&filesize computed in the background).
But I still see major issues with the DB:
- If I remove a folder with just 1 image in my 2GB cache, XnView will need to write/recompute a whole 2GB temporary file to remove that 5KB thumbnail...
- XnView is still reading 20 times each segment of the DB, which I believe has severe performance hit.
Pierre.
There is no way in SQL-lite to remove an image from DB (+reduce DB size) without rebuilding it???xnview wrote:Here it's the SQL DB command, not me
The 20x reading is a real problem with large folders, as the Disk/System can't cache everything (example: 500MB of thumbnails in RAM) -> the 20x real hit in performance probably happens there...
Olivier
I don't rebuild it, it's sql liteOlivier_G wrote:There is no way in SQL-lite to remove an image from DB (+reduce DB size) without rebuilding it???xnview wrote:Here it's the SQL DB command, not me
The 20x reading is a real problem with large folders, as the Disk/System can't cache everything (example: 500MB of thumbnails in RAM) -> the 20x real hit in performance probably happens there...
Pierre.
I have read a bit more about SQLite and in line with the first behaviour (DB not shrinking in size), I have a more accurate question: do you now use auto_vacuum for your DB?
Olivier
No, i use vacuum commandOlivier_G wrote:I have read a bit more about SQLite and in line with the first behaviour (DB not shrinking in size), I have a more accurate question: do you now use auto_vacuum for your DB?
Pierre.
Auto_vacuum is not a good solution, very slow on add/delete entriesOlivier_G wrote:I really wonder about the performance of auto_vacuum (doesn't rebuild DB???) vs vacuum, as it might improve things a lot... but would require to start DB from scratch again (cannot be added afterwards).
=> any feedback experience about this auto_vacuum?
Pierre.
Thank you for the feedback. So much for auto_vacuum, then...xnview wrote:Auto_vacuum is not a good solution, very slow on add/delete entries
Some suggestions to reduce workload in Cache panel:
- When removing folders, don't 'vacuum' at each removal. Use a flag instead to 'vacuum' when exiting Options (an alert with 'don't show next time' would be nice). Flag would also be reset after an 'Optimize' (which should include an immediate vacuum).
- I wonder whether it's useful to display filesize of every folder. The number of thumbnails and a single general "Database size"=[filesize] would be enough, IMO.
I would like to get some feedback about those suggestions.
Olivier