When it comes to performance, F-Spot hasn't always been the best of it's class. Part of my Summer of Code time has been spent on improving that. While reworking the editors (which will land soon), I ran into trouble spots, which I've started fixing. My mentor improved in these.

To show the difference, I've made a small unscientific benchmark. Below are the times needed to add 2 tags to a set of 1000 photos. During this amount of time, the user interface freezes.

Observe how the whole UI freezes for over 20 seconds in the currently released version. In SVN, you hardly notice it happening! This is a 44.5 times speedup!

Similar improvements are to be found everywhere. I'm most fond of the fact that the image doesn't reload anymore while adding tags. This means using type-to-tag (the t-hotkey) is now completely instant and a joy to use.

All of this is in SVN and will be available in the next release.

Wow! Well done. I'd love to see some posts about how you made it so much faster.

Good job! (and thank you Google)

F-spot's performance used to be even more horrendous. The first time I tried it, and asked it to import my photos (a couple of thousand), it crunched for at least 30 minutes and grew and grew until the OOM killer stepped in. I responded by erasing it from my system.

I'm glad you're working on improving it, but the performance of many operations has been so bad that the program has a rather bad reputation (so bad that once you've finished optimizing it, you might want to choose a new name to avoid the stink associated with the original program).

Did you seriously just use a 3D bar chart to display two numbers? Your chart makes it difficult to figure out the actual numbers, and the 3D perspective makes it even more difficult. I can only guess at "something between 0 and 5 seconds, probably on the low end" and "something between 20 and 25 seconds, probably in the middle". Please, just post the numbers next time. And when you really do need a chart, ditch the 3D, add more tick marks on the scale, and include the actual numbers anyway.

Ian: No plans yet for articles on that. Basically it boils down to the old adagio: To know is to measure. If you notice that you're doing *a lot* of database queries, it might be good to investigate upon that. Our problem was that change events were too coarse grained, causing way too much recalculations. Making the events more detailed led to most of the improvements.

Anders: Thanks!

Joe: It has been worse indeed. But renaming, just for that matter, sounds a bit harsh to me.

Anonymous: Please do have the guts to use your real name if you want to make a point. Doing it the anonymous coward way really harms your credibility. Anyway, you wanted exact numbers: F-Spot 0.4.4: 22.913s, F-Spot SVN: 0.514s, running on a Pentium M 1.7, on the table in my sunny garden. Fair enough? As for the 3D: Nobody cares about the exact numbers, it's loads faster, that's what matters. Besides, the numbers will probably completely different on your system (though SVN should always be faster).

Mellow out anonymous - this isn't a science paper.

Thanks Ruben. I did wonder why it was quite so slow.

Although my camera acts as a damn slow USB storage device even when you don't start f-spot..... ho hum

"Please do have the guts to use your real name if you want to make a point. Doing it the anonymous coward way really harms your credibility."

No, it does not. It does however seem to bother people who can't handle constructive criticism.

Every point Anonymous made is spot-on, and none of his points hinge on his credentials as some sort of expert whom we'd need to know something more about. He's right, and his anonymity doesn't change that.

If you don't like anonymous posts, then why not alter your blog so they're not allowed, rather than barking at anonymous posters who demonstrate they have a clue? There are plenty of valid reasons for posting anonymously that have nothing at all to do with "guts."

Good job, i hope the speed for reading the files to be imported faster.

Yaay it's faster! Now can someone please allow images to be moved instead of just copying when importing.

Good news indeed!

I first tried f-spot perhaps two years ago, and in the end it had enough problems - crashes, slowdowns - that I gave up on it. I tried it again last month and it's now so much better that I've gone over to it completely. Not that there aren't plenty of bugs and slowdowns still, but they're no longer enough to make using it infeasible.

In fact, it's at the point where I've started to toy with the idea of perhaps implementing a few features that I miss, like the ability to associate two imported images with each other so one of them is treated as a derivative of the other; or the ability to take the UFRaw parameter file from one developed raw image and apply the same parameter set to batch develop a whole set of marked raw images. I would very much want to have images with multiple versions to be visibly different from unedited images, perhaps with a hinted, abstract "stack" line shadow around those images. It would be nice, too, to have some kind of emblem showing which images have been uploaded to Flickr. And another I would like to see is for the Flickr-exporter to allow you to rearrange the uploaded image order.

Hello. The whole thing with bars and graphs are overrated.
What we need is data. For instance, bars and graphs are useless to blind people. So, a text (read: proper data) should always be there.

Am I the only one who does not care so much about the speed of tagging, but on the speed of the actual image display? Do you guys ever actually watch the photos you're tagging with so much care?
Honestly, rendering a dozen-megapixel image takes some time, but that's the reason why almost any crappy image viewer out there pre-renders the next few images so that you //don't// have to watch how the up-scaled preview image is slowly beeing replaced by the actual image.

Frieder: you're not the only one who is concerned about image displaying performance. I don't know if it's because of mono or is it because the way how is f-spot programmed. The performance is really crappy. I've just tried to program simple app to display images using java. It's much faster, less cpu intensive - I just used default java api(buffered image), I didn't use any threads or caching or something. Please do something about the displaying performance - it's very slow and my laptop fan is very loud while displaying pictures.

Believe me, we *are* concerned about all kinds of performance. Unfortunately, there's thousands of other things we have to take care of before we even get to investigating performance issues.

Now there's a very simple way to get this fixed (and I'm especially referring to you dixon, since you mentioned to know the issues): dive in the code. Given that most of us (and there's not much of us f-spot devs) are volunteers, we are always very glad to get extra help.

And it sure is faster than just complaining!

Name
Email (optional)
Website (optional)
Remember my personal details
Email me when there are new comments
Comment