[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    www/sites/kphotoalbum
From:       Jesper Pedersen <blackie () blackie ! dk>
Date:       2013-02-03 15:45:55
Message-ID: 20130203154555.7F554AC86E () svn ! kde ! org
[Download RAW message or body]

SVN commit 1337156 by blackie:

added news entry

 M  +42 -75    news.rss  
 A             news/0081  


--- trunk/www/sites/kphotoalbum/news.rss #1337155:1337156
@@ -15,8 +15,46 @@
 
 
 <item>
+<title>A Productive weekend - Saving now 3-4 times faster</title>
+<pubDate>3 Feb 2013 16:30:00 +0100</pubDate>
+<guid>http://www.kphotoalbum.org/index.php?page=news#item0081</guid>
+<link>http://www.kphotoalbum.org/index.php?page=news#item0081</link>
+<description>
+&lt;p&gt;This week we discussed saving times on the KPhotoAlbum IRC channel,
+which made me give it a shot at rewriting the saving code from QDom to
+QXmlStreamWritter. I had a hunch that it would give quite some nice
+improvement in saving speed.&lt;/p&gt;
+
+&lt;p&gt;Now, if you have ever participated in one of my Qt training classes, you
+will likely have heard me say something like &lt;i&gt;NEVER EVER trust your own
+hunches on where time is spend in your applications, USE A
+PROFILER!&lt;/i&gt;. Rewriting the code resulted in a disappointing 10% time
+reduction on saving, not the 50% or more I had hoped for. Sigh! Why do I
+never listen to myself?!&lt;/p&gt;
+
+&lt;p&gt;OK, so when I had callgrind and kcachgrind in action anyway, I could
+just as well look at what made it relatively slow at saving, and I found,
+not surprisingly, that it spend quite a bit of time in places I wouldn't
+have guessed in a million years. I got an impression 18% reduction simply
+by caching whether the XML file should be in compressed or readable
+format.&lt;/p&gt;
+
+&lt;p&gt;In total, depending on format used, and whether your KPhotoAlbum is
+build in debug or release mode, I got a reduction of time spend when
+saving between 62% and 73%, which means a speed up of 3-4.&lt;/p&gt;
+
+&lt;p&gt;Saving now takes less than 400ms on my database with 13800 images (of
+which more than 95% are tagged). I guess it will be a while before I need
+to revisit the speed of saving :-)&lt;/p&gt;
+ 
+&lt;p class="author"&gt;— Jesper&lt;/p&gt;
+</description>
+</item>
+
+
+<item>
 <title>KPhotoAlbum 4.3</title>
-<pubDate>26 Sep 2012 06:15:00 +0300</pubDate>
+<pubDate>26 Sep 2012 06:40:00 +0300</pubDate>
 <guid>http://www.kphotoalbum.org/index.php?page=news#item0080</guid>
 <link>http://www.kphotoalbum.org/index.php?page=news#item0080</link>
 <description>
@@ -25,12 +63,9 @@
 4.3&lt;/a&gt; available for download.
 &lt;/p&gt;
 &lt;p&gt;
-New features concentrate on video support improvements and background
-tasks. Also the database backend has been dropped completely leaving the
-XML backend as the only option. Automatic stacking of images based on
-file version detection has been brought to the maintenance menu giving
-control to the user instead of only performing the action upon starting
-of KPhotoAlbum.
+&lt;a href="#item0079"&gt;New features&lt;/a&gt; were described when announcing the
+beta version. Only minor bug fixing and addition of pattern based search
+was done since then.
 &lt;/p&gt;
 &lt;p class="author"&gt;— Miika&lt;/p&gt;
 </description>
@@ -200,74 +235,6 @@
 </item>
 
 
-<item>
-<title>Summer vacation means much faster thumbnail viewer.</title>
-<pubDate>16 Aug 2010 09:00:00 +0100</pubDate>
-<guid>http://www.kphotoalbum.org/index.php?page=news#item0071</guid>
-<link>http://www.kphotoalbum.org/index.php?page=news#item0071</link>
-<description>
-&lt;p&gt;I've just returned from one week of vacation on Zakynthos in Greece, and the
-result is the same as every year of summer vacation - a lot of time to
-spent on KPhotoAlbum :-)&lt;/p&gt;
 
-&lt;p&gt;This year I rewrote the thumbnail viewer from the old Q3IconView to
-Qt4's QListView, and while I was at it (and yes that was really my starting
-point), I optimized the loading of thumbnails quite a bit. We are talking
-about orders of magnitude here!&lt;/p&gt;
-
-&lt;h2&gt;The technical details - in case you care&lt;/h2&gt;
-&lt;p&gt;Just prior to my vacation I experienced with storing thumbnails in one
-large file, which is much faster to load than storing each thumbail in a
-file of their own. &lt;a href="http://www.kdedevelopers.org/node/4295"&gt;See the
-details in my blog&lt;/a&gt;&lt;/p&gt;
-
-&lt;p&gt;This is what I do now, but that really only contribute to a minor part
-of the speed up, it turned out that thumbnails was scaled when loaded from
-the cache - at the time that seemed like a good idea, but the result was
-that each thumbnail costed an extra 10 msec - which amounts to a whole
-second for 100 thumbnails. Now the images in the cache has the actual size
-needed. This means that it is flushed each time you resize the thumbnail -
-so stop doing that a lot :-)&lt;/p&gt;
-
-&lt;p&gt;Another slowdown was the drawing of the 3D effect around each
-thumbnail. By changing that from drawing 5 rectangles to drawing 5 filled
-rectangles, I got a huge speedup :-)&lt;/p&gt;
-
-&lt;h2&gt;What are the catch?&lt;/h2&gt;
-&lt;p&gt;So is this all great, no catch?, well there is a few minor ones.&lt;/p&gt;
-&lt;ul&gt;
-&lt;li&gt;We are storing the thumbnails in our own format now, so other
-     application wont be able to reused them - anyway, that has been so for
-     a few years already, so no big deal.&lt;/li&gt;
-&lt;li&gt;Thumbnails needs to be recreated when thumbnail size is
-     changed. This was the price we had to pay for this, as the
-     alternative, which we used before, was to store the images in say
-     256x256, and then scale them down, but that was exactly what costed a
-     lot.&lt;/li&gt;
-&lt;li&gt;When you resize the thumbnails, new thumbnails are generated for all
-the videos too. As the thumbnail for the videos are a random screenshot from
-the video, this means that it will change each time, which might make it
-harder to recognize them.&lt;/li&gt;
-&lt;li&gt;The old selection model of the thumbnail viewer has been replaced with
-     QListView's version. This means you do rectangle selections with the
-     mouse. I might rework that to use our own selection method again later
-     on, if there is a public demand for it.&lt;/li&gt;
-&lt;li&gt;I'm sure I've introduced a lot of new bugs :-)&lt;/li&gt;
-&lt;/ul&gt;
-
-&lt;h2&gt;What are the advantages?&lt;/h2&gt;
-&lt;ul&gt;
-&lt;li&gt;Much much faster - we are talking about smoooth scrolling now,
-     something like going over say 5-10 pages of thumbnails per second,
-     where the old implementation took perhaps 1-2 second per page.&lt;/li&gt;
-&lt;li&gt;The code has been rewritten to use Qt 4's QListView, which means a lot
-     of code had been cleaned up - to the end user this means fewer lines
-     for us developers to add bugs to :-)&lt;/li&gt;
-&lt;/ul&gt;
-</description>
-</item>
-
-
-
 </channel>
 </rss>
[prev in list] [next in list] [prev in thread] [next in thread]