GNOME Bugzilla – Bug 457487
High CPU usage
Last modified: 2018-07-01 08:58:25 UTC
Please describe the problem: This problem has been experienced not only from SVN but on all versions of f-spot so far. Steps to reproduce: 1. Browse photos. I have 600 in my collection. 2. Double-click a photo. Go back to browse. 3. Return to 2 and do that a couple of times. 4. Scroll up and down. Go to 2. Actual results: High CPU usage, nearly 100% Expected results: Normal CPU usage. Does this happen every time? Yes. Other information: Compiled on Ubuntu Edgy (6.10) ii mono 1.1.17.1-1ubun Mono CLI (.NET) runtime
You know, a cpu is meant to be used at 100%. opening images (depending on the format) IS a cpu intensive task with almost no polling on io, so it's normal to see a cpu at 100% during the image loading part. Or am I misunderstanding your problem ? Do you observe a high load on your system while doing nothing, after opening some images in f-spot ?
Stephane, sorry for being unclear in my bug report. What I meant is, that after doing the steps, and waiting for minutes doing nothing, the CPU usage is almost 100%. In the console, i cannot see that f-spot is doing anything, but it must be doing something. Is there any way I can see what is doing (enabling debug flags, or something else)? It would be so nice to hook a mono debugger up to it :-) The load is not very high: 14:47:10 up 10 min, 3 users, load average: 2.18, 2.24, 1.33 but it seems to be getting higher: 14:57:28 up 21 min, 3 users, load average: 2.26, 2.33, 1.82 10 minutes with no use of f-spot, CPU usage: 98%. I'm not sure what to rename this bug to: "High CPU usage when idle after stress test" or something?
can you paste here the first few lines (e.g. 15) of 'top' after a few minutes ?
Just after my test: 10309 cs 15 0 145m 64m 14m S 91.1 25.9 1:55.90 f-spot after four minutes: 10309 cs 15 0 145m 64m 14m S 81.9 25.9 6:20.09 f-spot the number fluctuates and minimum is about 80%, maximum 99%. 10309 cs 15 0 145m 64m 14m S 98.4 25.9 7:53.24 f-spot
sorry, just saw you said "few lines" 10309 cs 15 0 145m 64m 14m S 93.1 25.9 8:57.73 f-spot 4552 cs 15 0 81000 12m 8496 S 4.0 4.9 0:21.77 gnome-terminal 3817 root 15 0 117m 11m 5608 S 1.3 4.5 7:31.48 Xorg 4530 cs 15 0 233m 62m 20m S 1.0 25.1 5:41.50 firefox-bin 1 root 16 0 1628 476 428 S 0.0 0.2 0:01.76 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 5 root 10 -5 0 0 0 S 0.0 0.0 0:01.07 events/0 6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper 7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread 9 root 10 -5 0 0 0 S 0.0 0.0 0:00.16 kblockd/0
I can't reproduce it here, following the proposed steps... Are you using a fresh SVN snapshot?
I just reproduced it again using latest SVN.
That's strange... I tried again to reproduce the steps you proposed, but I couldn't get the same result... The cpu is going up, even to 100%, but from the moment it ends loading photos and I don't ask F-Spot to do nothing more, it goes back to 0%... Could you please try with a brand new db? Backup ~/.gnome2/f-spot/photos.db, and then remove it. Import a few photos, possibly not the same that are already into your photos db, and try. Does it happens again?
Christoffer: can you take a look at bug 479423 and see if my scenario applies to your situation?
Tried a brand new database, imported some pictures and now I have had f-spot running in 6 minutes with 100% CPU. I'm running on edgy like I posted in my original report, just so you know it.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.