<div dir="ltr">Another tidbit of information: decompressing samples is a serious time hog. Do not use compression if you can afford it AND need the performance.<div><br></div><div>I did not look into it further myself. I guess that we use a compression level that is too high.</div>
<div><br></div><div>Sylvain</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 3:18 PM, Sylvain Joyeux <span dir="ltr"><<a href="mailto:bir.sylvain@gmail.com" target="_blank">bir.sylvain@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey. Given that I already did the work, I thought that someone would like to pick it up.<div><br></div><div>
During the pocolog-related discussion (or "bashing", call it however you want), I profiled pocolog and found some very low-hanging fruits open for optimization. I've published the result as a PR on github</div>
<div> <a href="https://github.com/rock-core/tools-pocolog/pull/1" target="_blank">https://github.com/rock-core/tools-pocolog/pull/1</a></div><div><br></div><div>This is NOT tested for correctness (in other words, it works on test cases, but has not been fully tested). I won't take care of that, so feel free to take it and try it. The pull request describes what kind of performance enhancement ON POCOLOG you might expect. The rest of the tooling staying untouched do NOT assume that you will get the same improvement when running e.g. rock-replay</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Sylvain </div></font></span></div>
</blockquote></div><br></div>