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