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.
On Thu, Mar 19, 2015 at 1:25 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > Welcome! > > Thank you for your past work. Trying to emulate it concretized and > motivated almost all of my high school and undergraduate math classes. > > On 03/18/2015 02:59 PM, John Carmack wrote: > >> ... >> >> 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. >> > > What kind of Scheme did you have in mind? > > 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. > > On the other hand, it's easy to write a Scheme interpreter. But you don't > get the JIT, optimizer, and other goodies. > > I'm teaching my son with Racket. He has worked in a few different >> imperative languages prior. >> > > 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. > > 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. >> > > Listen to Jay. :) He doesn't use DrRacket, though, so he's left something > out. > > 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. > > 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. > > Neil ⊥ > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users
