[racket] "lab notebook on learning process" (was: Re: Macros baffle me)

> > > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140506/7fc6f498/attachment.html>