[Digikam-devel] [Bug 150938] Album thumbnail view very slow on NFS

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=150938         




------- Additional Comments From marcel.wiesweg gmx de  2007-10-21 21:51 -------
Bengt you are right and I am fully aware that caching can be improved. This will be improved in 0.10, but not backported to 0.9, this is an area of large changes. I am just currently finding out how to best build the cache in the ImageInfo objects, and in 0.10 ImageInfos as a whole will be shared under the hood (only one object per image across the application)

The const problem is solved using const_cast, this seems all right, because lazy caching is one of the fields where people say const_cast can be used.

Nevertheless, you are curing symptoms, but the disease is that SQLite over NFS is extremely slow. A database call is relatively slow, slower than looking up in a cache, so we need to cache, but digikam is based on the db, so we cannot support situations where the db is really slow.

A second case you mention is "accessing the album from several computers". I understand that as "sharing the database file"? No of course that does not work when the db file is stored locally.
One solution would be to support MySQL for such cases. Concurrent access is still a different story, but what you want is to access your pictures and your database from several computers at different times. If we supported MySQL this would solve your problems. In 0.10 we use Qt SQL as database backend, so support for MySQL is no problem in principle. What needs to be done is to test/adapt our SQL code with knowledge of the faint differences in supported SQL (I do not have this knowledge)