<br><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 5:01 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, 7 Feb 2012, Dmitry Kazakov wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Compression<br>
For the actual compression of the tile data we use LZF algorithm. I did some research on the compression times of LZO and LZF [0], [1]. It<br>
turned out that LZF has better times. It takes twice faster to compress the image with LZF while keeping almost the same compression rate.<br>
One more thing I found then is that it is faster to "linearize" colors before compression and then compress the image than compress the<br>
image directly (RGBARGBA -> RRGGBBAA). It boosts both the speed and the compression rate. The time of the "linearization" itself is<br>
negligible in comparison with the boost it give, so now we do it this way.<br>
<br>
</blockquote>
<br></div>
Well, actually when Sven wanted to know why loading and saving files is so slow, it turns out that the linearization is the biggest bottleneck we currently have! But that might depend a lot on cache sizes and so on. In<br>

general, we want to avoid missing the cache when compressing a tile.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Probably, I'm a bit outdated.<br><br>I've just run the test on my new machine.<br>
The results are the following:<br><br><span style="font-family:courier new,monospace">Compression LZF w/o  linearization: 247 memcpy's. Ratio: 0.938</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Compression LZF with linearization: 213 memcpy's. Ratio: 0.769</span><br style="font-family:courier new,monospace">
<br></div></div><span style="font-family:courier new,monospace">Decompression LZF w/o  linearization:  78 memcpy's.</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace">Decompression LZF with linearization: 112 memcpy's.</span><br style="font-family:courier new,monospace">
<br>It means that for compression the linearization still makes it faster, but for decompression it makes the things worse on newer cpu. Here are the callgrind graphs for compression and decompression: [0], [1]<br><br>[0] - <a href="http://dimula73.narod.ru/callgrind.out.9540_compression_two_pass">http://dimula73.narod.ru/callgrind.out.9540_compression_two_pass</a><br>
[1] - <a href="http://dimula73.narod.ru/callgrind.out.9513_decompression_two_pass">http://dimula73.narod.ru/callgrind.out.9513_decompression_two_pass</a><br><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>