<div>This part sparked a thought with me later;</div><div><br></div><div><div>Obviously in any case the following is like a very low priority question as performance is good already:</div></div><div><br></div><div><br>Marc, the current GC and the future GC, does it iterate by depth or breadth?</div>

<div><br></div><div>If the further, indeed the order of objects will generally be extremely close in RAM after any GC copy operation, which would be beneficial from the CPU caching point of view, while with the latter they'd be apart.</div>

<div><br></div><div>(Obviously solid objects like strings and special type vectors are always 'close in memory' with themselves.)</div><div><br></div><div>Example:</div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">

<div><br></div><div><font face="courier new, monospace">(define a (vector b c))</font></div><div><font face="courier new, monospace">(define d (vector e f))</font></div><div><font face="courier new, monospace"><br></font></div>

<div><font face="courier new, monospace">(define g (vector a d))</font></div></blockquote></div><div><br></div><div>If by depth the order in RAM after GC copy would be g a b c d e f, and if by breadth, g a d b c e f. </div>

<div><br></div>Regards,<div>Mikael<br><br><div class="gmail_quote">2013/1/5 Mikael <span dir="ltr"><<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>></span><br><div>.. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div></div><div>Scheme </div></blockquote><div>[..]</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>is not exactly as heavily optimized for contemporary CPU caching as </div>

</blockquote><div>[..]</div><div>..</div><div><br></div></div></div>