<div dir="ltr">I will second that. The performance difference between the racket dedicated executable, and running something under a DrR REPL can be surprisingly huge. It's one of the reasons why I've been slowly transitioning to using racket-mode under Emacs instead.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 1:25 PM, Neil Toronto <span dir="ltr"><<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Welcome!<br>
<br>
Thank you for your past work. Trying to emulate it concretized and motivated almost all of my high school and undergraduate math classes.<br>
<br>
On 03/18/2015 02:59 PM, John Carmack wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<span class=""><br>
<br>
I have a specification for a VR related file format that is headed towards JSON, but I am seriously considering changing it to s-expressions and embedding a trivial (not Racket) Scheme for scripting.<br>
</span></blockquote>
<br>
What kind of Scheme did you have in mind?<br>
<br>
It's not terribly hard to embed Racket, nor to create a "#lang" language that gives access to only the leanest parts of the language and libraries.<br>
<br>
On the other hand, it's easy to write a Scheme interpreter. But you don't get the JIT, optimizer, and other goodies.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm teaching my son with Racket.  He has worked in a few different imperative languages prior.<br>
</blockquote>
<br></span>
If he's interested in 3D, he might like Pict3D, a 3D engine written in Racket that has a purely functional interface. (Most of the internals are purely functional as well.) Disclaimer: the API is stable, but I'm still expanding it, and I haven't used my own kids as guinea pigs yet.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would be interested in hearing any guidance for high performance servers written in Racket.  GC delays in the tens of milliseconds will be problematic for at least part of this application, but I could split that part off into a separate server and still leave the other part in Racket if necessary.  The main benefit is currently development productivity, so obnoxious micro-architectural optimizations aren't useful, but broad strategic guidelines would be appreciated.<br>
</blockquote>
<br></span>
Listen to Jay. :) He doesn't use DrRacket, though, so he's left something out.<br>
<br>
When you do performance testing and statistical profiling, it's fine to use DrRacket if you turn off debugging and (the other) profiling support, and uncheck "Preserve stacktrace" in the "Choose Language" dialog.<br>
<br>
But when measuring GCs, run programs from the command line. DrRacket and its tools use a lot of heap. In their initial state, this adds about 10ms to minor collections and 500ms to major collections. Using Typed Racket will magnify the differences because its compile-time analysis is quite memory-heavy.<span class="HOEnZb"><font color="#888888"><br>
<br>
Neil ⊥</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
____________________<br>
 Racket Users list:<br>
 <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/<u></u>users</a><br>
</div></div></blockquote></div><br></div>