<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">I'm principle ok with the naming (though it would be nice to add "projection"</div>
</div>
to the walkers, I think), </blockquote><div>It has a word "Merge" inside. Now every layer has it's own "projection". I guess it should be called more general.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
but I'm wondering about the performance impact. It<br>
has become quite a complex beast! Have you any insight in the performance?</blockquote><div><br></div><div>Yeah, there surely be some performance penalty. Though every parallelization technique has it's penalty on uniprocessor machine.</div>
<div>You see, now the merge is done in two steps:</div><div><br></div><div><div>1) walker.collectRects(node, rc);</div><div>2) merger.startMerge(walker);</div></div></div><div><br></div><div>The second step was indirectly present in a previous version. The first one is completely new. And the slowest part in the first step is allocating a stack of size N, where N - number of layers. (I think this is the slowest, should check)</div>
<div><br></div><div>Though we shouldn't forget that this very "beast" is a small bugfix actually =) It fixes "border-effect" problem, that can't be really fixed in other way (read: i don't know how to fix it in other way:) ). And it creates the ground for safe parallelization.</div>
<div><br></div><div>PS:</div><div>I should add a creation of a simple performance benchmark to my todo-list...</div><div><br></div><br>-- <br>Dmitry Kazakov<br>