Around 50% performance drop from 8.0 to 9.0

[GoogleCodeExporter]

It would be nice if the new version would match the thumbnail performance (no  
embedded thumbnails) of the 8.0-8.2 version.

Original issue reported on code.google.com by modernv...@arcor.de on 7 Oct 2010 at 6:43

[GoogleCodeExporter]

Hi Jens, I ran a few benchmarks with a few large images:

With embedded thumbnails option all versions from 8.0 have similar performance:

  ImageListView_8.0.dll extracted 46 embedded thumbnails in 1150 milliseconds.
  ImageListView_8.1.dll extracted 46 embedded thumbnails in 1165 milliseconds.
  ImageListView_8.2.dll extracted 46 embedded thumbnails in 1191 milliseconds.
  ImageListView_8.3.dll extracted 46 embedded thumbnails in 1208 milliseconds.
  ImageListView_9.0.dll extracted 46 embedded thumbnails in 1189 milliseconds.

Without using embedded thumbnails:

  ImageListView_8.0.dll extracted 46 thumbnails in 1077 milliseconds.
  ImageListView_8.1.dll extracted 46 thumbnails in 4339 milliseconds.
  ImageListView_8.2.dll extracted 46 thumbnails in 4176 milliseconds.
  ImageListView_8.3.dll extracted 46 thumbnails in 4013 milliseconds.
  ImageListView_9.0.dll extracted 46 thumbnails in 3980 milliseconds.

There is clearly a difference between the 8.0 version and later versions 
without using embedded thumbnails. The change appears to be introduced between 
8.0 and 8.1. I don't have any ideas yet but I'm looking into it. Benchmark 
utility is attached; please let me know if you find something different.

Thanks,
Ozgur

Original comment by oozcitak on 8 Oct 2010 at 1:34

• Changed state: Accepted

Attachments:

• ImageListViewBench.zip
• ImageListViewBench_Source.zip

[GoogleCodeExporter]

Oh and also I ran benchmarks on older versions of the control too. Without 
embedded thumbnails, the control is about 5 times faster; thanks to WIC and 
you. I thought you'd like to know. :)

  ImageListView_5.0.dll extracted 46 thumbnails in 18995 milliseconds.
  ImageListView_6.0.dll extracted 46 thumbnails in 19272 milliseconds.
  ImageListView_7.0.dll extracted 46 thumbnails in 18753 milliseconds.
  ImageListView_8.0.dll extracted 46 thumbnails in 1068 milliseconds.
  ImageListView_9.0.dll extracted 46 thumbnails in 3975 milliseconds.

Thanks,
Ozgur

Original comment by oozcitak on 8 Oct 2010 at 1:43

[GoogleCodeExporter]

There was a bug in v8.0 in ThumbnailExtractor.cs. It always used embedded 
thumbnails regardless of the UseEmbeddedThumbnails property. Here is the diff 
between v8.0 (left) and v8.1 (right):

http://code.google.com/p/imagelistview/source/diff?spec=svn420&old=402&r=420&for
mat=side&path=/trunk/ThumbnailExtractor.cs

Take a look at line 153 on left.

It appeared fast because it was always loading embedded thumbnails.

Thanks,
Ozgur

Original comment by oozcitak on 8 Oct 2010 at 5:06

[GoogleCodeExporter]

the folder browser window is not working correctly............

Original comment by medhelpn...@gmail.com on 9 Oct 2010 at 5:36

Attachments:

• ImageListView.jpg

[GoogleCodeExporter]

The cause is not the UseEmbeddedThumbnails property because the images I use 
for testing don't have embedded thumbnails.

I downloaded ImageListViewBench and there's no (major) performance difference 
between 8.0, 8.3 and 9.0 no matter what options (autoRotate, 
UseEmbeddedThumbnails) I select. I'm guessing the performance difference 
between demo(!) version 8.0-8.3 and 9.0 lies somewhere else. It might(!) be an 
ordering or display issue since version 9.0 displays the thumbnails from top to 
bottom while 8.0-8.3 displays them from bottom to top with a few random 
out-of-order thumbnails in-between.

There's a slight chance that this behavior is multi-processor/multi-thread 
related (I have an 4 cores/4 threads processor). WIC codecs have to support 
async decoding, so your queue-based approach of 9.0 might not be optimized yet.

-Jens

Original comment by modernv...@arcor.de on 9 Oct 2010 at 10:19

[GoogleCodeExporter]

Thanks Jens, there was indeed a problem with ordering. v9.0 uses a queue while 
processing thumbnails, while prior versions used a stack. This is the cause of 
the ordering issue. I changed the thread to use a LIFO work queue instead of 
FIFO. Using a stack makes more sense because when the user scrolls the view, 
the last thumbnails made visible should be the first ones to be loaded.

I also modified the worker threads to use less context switches and prevented 
the worker threads from refreshing the control, if the newly loaded thumbnail 
is not visible.

I did more detailed benchmarks and there seems to be some improvement. Results 
below:

https://spreadsheets.google.com/ccc?key=0Aue8w7GPjATXdG91VHVGUjI5T0VmZlpkdGx4dHF
QRlE&hl=en&authkey=CPfkwNEO

I'll be releasing these changes as 9.1. Next, I'll try multiple threads or a 
ThreadPool for thumbnail processing.

Thanks,
Ozgur

Original comment by oozcitak on 9 Oct 2010 at 11:00

[GoogleCodeExporter]

I repeated the benchmarks for all releases from 8.0. Today's 9.3 release is the 
fastest so far. Results below:

https://spreadsheets.google.com/ccc?key=0Aue8w7GPjATXdEFXVzlEc0Z3elYyN2F0UEhrTXl
kcWc&hl=en&authkey=CPmh7J4P

Original comment by oozcitak on 13 Oct 2010 at 9:15

[GoogleCodeExporter]

I got even better results :) Demo version 9.3 is at least twice as fast as demo 
version 8.0. Great multi-core performance as well: I get 100% utilization on 
all 4 cores. I'm really impressed!

I encountered 2 bugs though:
1. Metadata fall-back to .net 2.0 doesn't seem to work.
2. In Pane und Gallery mode, sometimes the enlarged image won't be displayed 
until the cursor hovers over a different thumbnail.

Nevertheless, great version!

-Jens

Original comment by modernv...@arcor.de on 13 Oct 2010 at 10:59

[GoogleCodeExporter]

Great news, thank you. I don't have 4 cores to test (actually I am not even 
sure if I have one core on this old notebook :) but great to know that the 
multi-thread approach worked. 

I'll look at the bugs you encountered. Can I ask you to create new issues for 
them?

Cheers,
Ozgur

Original comment by oozcitak on 13 Oct 2010 at 11:18

[GoogleCodeExporter]

I moved the last two issues you reported into issue 107 and issue 108.

Original comment by oozcitak on 14 Oct 2010 at 8:05

• Changed state: Fixed