<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">If I (define i->c integer->char), and use it in your test1, it becomes the slowest.<div>That might mean that the "unknown function" response from Dr F applies to your function, too.<br><div>In other words, I think this is another example of drawing ambiguous conclusions from tests that are too simple.</div><div>I gave up on benchmarks long ago, because there are too many people outsmarting too many other people. </div><div><br></div><div>Interesting, though (uh oh, I am getting sucked in): </div><div>In v5.3.1 all of your tests are the same speed.</div><div>I even added some tests that use 'currying' to perhaps prevent the conversion function from being "inspected" on every call, and those are the same speed, too.</div><div><br></div><div>So it seems that the outsmarting peeps who wrote v6.1 optimized your first test, somehow, to make it twice as fast when it uses a "known function".</div><div><br></div><div>I am somehow reminded of the Fortran days and "intrinsic functions", but don't know if that is the same issue as this one.</div><div><br></div><div>rac</div><div><br></div><div><br><div><div>On Aug 3, 2014, at 3:15 AM, Roman Klochkov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div><p>Are higher order function always slow?<br><br>Made small test:<br>test1 -- unfamous set-in-the-loop accumulating<br>test2 -- built-in build-string<br>test3 -- manually written build-string with the same code as in test1<br>----<br>(define (test1 n)<br> (define res (make-string n))<br> (for ([i (in-range n)])<br> (string-set! res i (integer->char i)))<br> res)</p><p>(define (test2 n)<br> (build-string n integer->char))</p><p>(define (build-string1 n proc)<br> (define res (make-string n))<br> (for ([i (in-range n)])<br> (string-set! res i (proc i)))<br> res)</p><p>(define (test3 n)<br> (build-string1 n integer->char))</p><p>(time (for ([i 100000]) (test1 100)))<br>(time (for ([i 100000]) (test1 100)))<br>(time (for ([i 100000]) (test1 100)))<br>(displayln "")<br>(time (for ([i 100000]) (test2 100)))<br>(time (for ([i 100000]) (test2 100)))<br>(time (for ([i 100000]) (test2 100)))<br>(displayln "")<br>(time (for ([i 100000]) (test3 100)))<br>(time (for ([i 100000]) (test3 100)))<br>(time (for ([i 100000]) (test3 100)))<br>----<br>Tested on Linux x32</p><div></div><div><div>$ /usr/racket/bin/racket </div><div>Welcome to Racket v6.1.</div><div>> (enter! "test") </div><div>cpu time: 360 real time: 469 gc time: 64</div><div>cpu time: 212 real time: 209 gc time: 0</div><div>cpu time: 208 real time: 208 gc time: 0</div><div><br></div><div>cpu time: 400 real time: 402 gc time: 0</div><div>cpu time: 380 real time: 382 gc time: 4</div><div>cpu time: 384 real time: 383 gc time: 0</div><div><br></div><div>cpu time: 524 real time: 529 gc time: 4</div><div>cpu time: 468 real time: 470 gc time: 8</div><div>cpu time: 412 real time: 414 gc time: 12<br><br>---<br><br></div></div><div>So I see, that build-string version is about two times slower, than set-in-the-loop. Why so much? I expected about 10-20% difference.</div><br>-- <br>Roman Klochkov</div>
____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a><br></blockquote></div><br></div></div></body></html>