<div dir="ltr">To boil down my comments (and perhaps be clearer), my view is:<div>1. For someone who is running micro-benchmarks to 'shop' for a language+implementation, the standard advice is right: benchmark with command-line racket.</div>
<div>2. For a new user concerned about performance under DrRacket, I think such users would benefit a better explanation of the options, for example:</div><div> (a) why use the default configuration (leave 'debugging' and 'preserve stack trace' on), what extra info does it give</div>
<div> (b) turn off debugging and preserve stack trace to get better performance, but less debug info</div><div> (c) if neither of those option works for the user, then use emacs (especially if they are already an emacs user)</div>
<div>Also, other factors that would affect performance under DrRacket vs. command line racket (such as the work DrRacket itself is doing, which (among other things) will cause more garbage collection to happen.</div><div>
3. For more serious users, the real question is where will your code run? That's the environment in which you should measure run times. Even if it is in DrRacket, with 'debugging' and 'preserve stack trace' turned on.</div>
<div><br></div><div>Much of the discussion on performance seems to address mainly #1, and somewhat #2; #3 is actually the more important topic in my case, but not something I see discussed.</div><div><br></div><div>Jim</div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 4:52 PM, Jim Bender <span dir="ltr"><<a href="mailto:jim.bender@gmail.com" target="_blank">jim.bender@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Jim</div><div><br></div></font></span></div>
</blockquote></div><br></div></div></div>