Digikam slow
Locked
12
12
 
|
Hi
Am Saturday 08 December 2007 schrieb Dotan Cohen: > Actually, I meant KDE ingredients -> File Manager -> Thumbnails and > Metadata -> Maximum Size which I had set to 100.0 MB. However, I am > now not as convinced as I once was that this controls the size of the > _digikam_ thumbnails cache. I thought that they were one and the same I don't think that controls the size of .thumbnail. 1. On my system it is set to 5 MB and as I mentioned before, my .thumbnail directory has a size of 70 MB 2. The option says "Maximum file size". So I think that controls the maximum size of a thumbnail in konqueror and/or dolphin. The question is who controls the size of the .thumbnail directory and how exactly does the thumbnail caching work. I'm not a developer, so I can't answer that. One thing you could test. 1. Create two albums with only a couple of pictures (e.g. 5 each) 2. View both albums in digikam (the thumbnails should be cached now). 3. Open a command line and type "touch testfile" 4. View both albums in digikam again 5. In command line do "find ~/.thumbnails -newer testfile" If find prints some files then new files have been written or changed. If their are no new files than the caching in general works. I did this on my system. No new files here. If you do not get any files you can do the same test with your big albums. If there are new thumbnails you either hit a limit or the caching doesn't work properly. How many files do you have in .thumbnail? find ./~thumbnails -type f | wc -l How long does an ls -l in your .thumbnails directory take? I'm a unix admin and one problem my customers usually have is that they do not clean their directories. In some cases they have over 60000 files in a directory. ls is going smooth, but "ls -l" (reading the file meta data) is slow as hell. I don't think thats your problem, because I would expect a high system load and you didn't have one. You can not clean the .thumbnails directory (you cache would be gone). But I saw that "all files" are in one directory. A structure like squid or postfix is usally much more performant. Andreas -- My Public GPG Key: http://www.silicoids-world.de/gpg.asc Q: What is orange and goes "click, click?" A: A ball point carrot. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
Dnia Saturday 08 of December 2007, Dotan Cohen napisał:
> Actually, I meant KDE ingredients -> File Manager -> Thumbnails and > Metadata -> Maximum Size which I had set to 100.0 MB. However, I am This option controls when Konq should stop generate thumbnail per item. Eg. if you set this to 5M and image is bigger than 5M Konq will show only icon. m. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
Am Friday 07 December 2007 schrieb Dotan Cohen:
> On 02/12/2007, Mikolaj Machowski <[hidden email]> wrote: > > Dnia Saturday 01 of December 2007, Dotan Cohen napisał: > > > The system: Ubuntu Feisty on AMD Duron 1.3 GHz, 1GB RAM, KDE 3.5.6, > > > Digikm 0.9.2, 13,100 pictures in Digikam library which is on it's own > > > disk partition. KDE thumbnails cache opened up to 100MB. > > > > > > The problem: Digikam is so slow that it is nearly unusable. When we > > > open a folder/album in digikam we must wait 8 seconds before we see > > > thumbnails. Then, they trickle in at 0.87 sec per thumbnail (200 > > > thumbnails in two minutes, 54 seconds on the clock). When a photo is > > > deleted, we wait 8 seconds before there is any UI reaction. > > > > > > All apps run sluggish on this machine, but Digikam is really bad. What > > > can I do to tweak it a bit? I may be an old timer, but in my opinion a > > > 1300 MHz processor (with 1024MB RAM) should not be this bad. > > > > What disk do you have? > > What returns: > > > > hdparm -tT {device} > > On an otherwise idle system, I get this for the drive on which > /home/user/pictures is running: > ubuntu@ubuntu-desktop:~$ sudo hdparm -tT /dev/sdb1 > Password: > > /dev/sdb1: > Timing cached reads: 340 MB in 2.01 seconds = 169.46 MB/sec > Timing buffered disk reads: 190 MB in 3.03 seconds = 62.79 MB/sec > ubuntu@ubuntu-desktop:~$ Your cahced reads seem extremely slow to me. Look at what I get: sudo hdparm -tT /dev/sdb1 /dev/sdb1: Timing cached reads: 7186 MB in 2.00 seconds = 3594.65 MB/sec Timing buffered disk reads: 174 MB in 3.01 seconds = 57.77 MB/sec My disk seems to be a bit slower than yours, but the buffered read is always >50 times faster, whereas yours is only 3x faster. I have no idea what the problem could be. Gerhard > Dotan Cohen > > http://what-is-what.com > http://gibberish.co.il > א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users -- ><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º> http://www.gerhard.fr _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Andreas Weigl-2
On 08/12/2007, Andreas Weigl <[hidden email]> wrote:
> One thing you could test. > > 1. Create two albums with only a couple of pictures (e.g. 5 each) > 2. View both albums in digikam (the thumbnails should be cached now). > 3. Open a command line and type "touch testfile" > 4. View both albums in digikam again > 5. In command line do "find ~/.thumbnails -newer testfile" > > If find prints some files then new files have been written or changed. If > their are no new files than the caching in general works. > I did this on my system. No new files here. No new files. > If you do not get any files you can do the same test with your big albums. > If there are new thumbnails you either hit a limit or the caching doesn't work > properly. I ran Recreate Thumbnails, then touch testfile, then browse a few directories. Sure enough, there are some new files in ~/.thumbnails. So I've either hit a limit or there is a caching problem. How can I test that? > How many files do you have in .thumbnail? > find ./~thumbnails -type f | wc -l In ~/.thumbnails/large there are 5082 files. In ~/.thumbnails/normal there are 4531 files. Contrast that with 10825 files currently in ~/pictures/digikam > How long does an > ls -l > in your .thumbnails directory take? An instant. However, in ~/.thumbnails/large it took 3.5 seconds, and in ~/.thumbnails/normal another 3.5 seconds. > I'm a unix admin and one problem my customers usually have is that they do not > clean their directories. In some cases they have over 60000 files in a > directory. ls is going smooth, but "ls -l" (reading the file meta data) is > slow as hell. I don't think thats your problem, because I would expect a high > system load and you didn't have one. > You can not clean the .thumbnails directory (you cache would be gone). But I > saw that "all files" are in one directory. A structure like squid or postfix > is usally much more performant. Is that something that I can arrange, or would it be an internal digikam issue? Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
On 08/12/2007, Mikolaj Machowski <[hidden email]> wrote:
> Dnia Saturday 08 of December 2007, Dotan Cohen napisał: > > Actually, I meant KDE ingredients -> File Manager -> Thumbnails and > > Metadata -> Maximum Size which I had set to 100.0 MB. However, I am > > This option controls when Konq should stop generate thumbnail per item. > Eg. if you set this to 5M and image is bigger than 5M Konq will show > only icon. Ahhh... Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
Dnia Saturday 08 of December 2007, Dotan Cohen napisał:
> > > > What disk do you have? > > What returns: > > > > hdparm -tT {device} > > On an otherwise idle system, I get this for the drive on which > /home/user/pictures is running: > ubuntu@ubuntu-desktop:~$ sudo hdparm -tT /dev/sdb1 > Password: > > /dev/sdb1: > Timing cached reads: 340 MB in 2.01 seconds = 169.46 MB/sec > Timing buffered disk reads: 190 MB in 3.03 seconds = 62.79 MB/sec > ubuntu@ubuntu-desktop:~$ I have even slower results than you but digiKam works much faster: root@localhost ~ # hdparm -tT /dev/hdc1 /dev/hdc1: Timing cached reads: 266 MB in 2.00 seconds = 132.97 MB/sec Timing buffered disk reads: 178 MB in 3.04 seconds = 58.61 MB/sec root@localhost ~ # I wonder how Gerhard gets his results... m. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
Hi
Am Saturday 08 December 2007 schrieb Dotan Cohen: > > If find prints some files then new files have been written or changed. If > > their are no new files than the caching in general works. > > I did this on my system. No new files here. > > No new files. This means the caching basically works. Good. > I ran Recreate Thumbnails, then touch testfile, then browse a few > directories. Sure enough, there are some new files in ~/.thumbnails. > So I've either hit a limit or there is a caching problem. How can I > test that? I think this can only be answered by the developers because I do not know the caching algorithm. Does anybody know a description of the algorithm besides the source code? > An instant. However, in ~/.thumbnails/large it took 3.5 seconds, and > in ~/.thumbnails/normal another 3.5 seconds. So you do not have a problem with reading the directory contents. I didn't thought you have but it is always good to check. > > You can not clean the .thumbnails directory (you cache would be gone). > > But I saw that "all files" are in one directory. A structure like squid > > or postfix is usally much more performant. > > Is that something that I can arrange, or would it be an internal digikam > issue? This is digikam internal. If I have some time I will have a look on the source code. But my C programming skills are very poor. Andreas -- My Public GPG Key: http://www.silicoids-world.de/gpg.asc Too much is just enough. -- Mark Twain, on whiskey _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2007/12/8, Andreas Weigl <[hidden email]>: Hi This is the code of thumbs cache implementation: http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/digikam/pixmapmanager.h?revision=670778&view=markup http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/digikam/pixmapmanager.cpp?revision=670778&view=markup PixmapManager class use internally QCache from Qt to store thumb in memory. All is explained in Qt API doc http://doc.trolltech.com/3.3/qcache.html Note than QCache instance is used with this constructor : QCache<QPixmap>(101, 211); Gilles Caulier > An instant. However, in ~/.thumbnails/large it took 3.5 seconds, and _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 08/12/2007, Gilles Caulier <[hidden email]> wrote:
> This is the code of thumbs cache implementation: > http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/digikam/pixmapmanager.h?revision=670778&view=markup > http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/digikam/pixmapmanager.cpp?revision=670778&view=markup > > PixmapManager class use internally QCache from Qt to store thumb in memory. > All is explained in Qt API doc > > http://doc.trolltech.com/3.3/qcache.html > > Note than QCache instance is used with this constructor : > > QCache<QPixmap>(101, 211); Assuming that I can build an alternative Digikam that won't risk our valuable family photo album, I can gladly test patches that will make the program faster (cache better) for everybody. If my particular machine is the slowest one out there (therefore best displaying this particular weakness), then I gladly offer it for testing. If Gilles, Andreas, or Mikolaj want I can set you up with SSH access to a limited (non-root) account on this slow box. Gladly. After I set up a replacement machine for our personal use, you can even have root. Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |