<div dir="ltr"><div>> > > > Why does he think "Performance sucks"?</div><div>> > > </div><div>> > > Because here's the list of things that are slow</div><div>> </div><div>> DrRacket is an operating system running on top of your other OS</div>
<div>> to make life for Racket developers simple. It was originally developed</div><div>> for beginners, but I eat my own dog food, and I find it good (tm) for</div><div>> every day Racket work. </div><div>> </div>
<div>> To evaluate performance, run the programs at the command line. Measure</div><div>> there. Compare with other dynamically typed languages and report back </div><div>> what you find. If you still report performance problems, try to be precise. </div>
<div>> We are proud of Matthew and how far he has pushed Racket's performance on</div><div>> real software, the kind you use on a daily basis, not just minibenchmarks.</div><div><br></div><div>I've seen and appreciate the performance improvements in Racket that Matthew </div>
<div>has achieved over the years (and still improves each release); also, DrRacket </div><div>is the IDE I use when I am doing Racket programming, and I am very happy with it.</div><div>But, when this topic comes up, I often have some unease about the above reply.</div>
<div><br></div><div>In the points below, I am attempting to articulate why I don't find (what</div><div>seems to be) the standard reply quite satisfying. This isn't intended as</div><div>criticism, just a different perspective on the DrRacket performance topic.</div>
<div><br></div><div>I fully agree, that if I have a Racket program that deals with very large inputs </div><div>that takes 10 minutes or longer to run at the command lind under racket, I have </div><div>no business running it under DrRacket, where it will take a lot longer (and for</div>
<div>good reasons). And equally, I think that for mostly interactive programs,</div><div>running under DrRacket is usually just fine.</div><div><br></div><div>But there are also programs that will run under DrRacket, by design / intention.</div>
<div>For example, the implementation of a #lang language-- in a sense the whole point</div><div>of writing a #lang language, rather than just a 'standalone' compiler (intended </div><div>to be run at the command line) is to inherit DrRacket as the IDE for the new </div>
<div>language. At the same time, I think one has to be very careful about program analyses/</div><div>optimizations built in to the implementation of the #lang language. It's all well</div><div>and good to measure performance of such analyses at the command line, but performance</div>
<div>under DrRacket also obviously matters, when that may be the primary environment</div><div>in which the analyses run. If they are too slow under DrRacket, they might</div><div>have to be removed from the language implementation.</div>
<div><br></div><div>While the performance concern may often expressed on this list using mini/micro</div><div>benchmarks, I think in many cases, this is just a convenient means for users </div><div>to express what they are seeing with their actual programs.</div>
<div><br></div><div>To the extent that performance of a specific program under DrRacket matters,</div><div>"offshoring" the timing/benchmarking to a command line racket process isn't </div><div>going to help.</div>
<div><br></div><div>Lastly, my impression is that many newcomers to Racket don't, at least initially,</div><div>understand what factors contribute to the performance differences of running </div><div>under DrRacket vs. racket at the command line vs. racket using emacs or vim as the</div>
<div>ide. It might help to more clearly explain what is happening in the default mode</div><div>with debugging / profiling enabled, and why that is slower. In contrast, running</div><div>racket programs from emacs probably doesn't run as slow, but also wouldn't have </div>
<div>the debugging capabilities present in DrRacket. (And, even when one turns off the </div><div>debugging in DrRacket, performance ususally will be slower just because one </div><div>has GC pauses that might be caused by DrRacket instead of the user's program.)</div>
<div><br></div><div>Jim</div><div><br></div></div>