<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 12:37 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</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 11/2/2010 12:25 PM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And of course one can consider using thisContext instead of Object new<br>
or {}, since thisContext has to be instantiated anyway for the closure<br>
in fold:, and so results in less memory pressure. This needs careful<br>
measurement; you have the test bed set up for that; my workspace hacks<br>
are showing too much variability to distinguish.<br>
</blockquote>
<br></div>
I'm sorry but if your application is limited by the performance of reduce/fold you're doing it wrong. Can we discuss *clarity* of the solution over performance please? If we'd really need a high-performance variant, then *nothing* beats a trivial custom implementation in Array along the lines of:<br>
<br>
Array>>reduce: aBlock<br>
<br>
result := self at: 1.<br>
2 to: self size do:[:i| result := aBlock value: result value: (self at: 1)].<br>
<br>
-- "Premature optimization is the root of all evil" --<br></blockquote><div><br></div><div>I know. I'm joking ;) It's still interesting to see how code generator fallibilities make measurable differences. I did say I thought the whoorish speed differences were too ugly to contemplate.</div>
<div><br></div><div>best</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>