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

To boil down my comments (and perhaps be clearer), my view is:
1. For someone who is running micro-benchmarks to 'shop' for a
language+implementation, the standard advice is right: benchmark with
command-line racket.
2. For a new user concerned about performance under DrRacket, I think such
users would benefit a better explanation of the options, for example:
   (a) why use the default configuration (leave 'debugging' and 'preserve
stack trace' on), what extra info does it give
   (b) turn off debugging and preserve stack trace to get better
performance, but less debug info
   (c) if neither of those option works for the user, then use emacs
(especially if they are already an emacs user)
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.
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.

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.

Jim


On Tue, May 6, 2014 at 4:52 PM, Jim Bender <jim.bender at gmail.com> wrote:

> > > > > 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/b469c07a/attachment-0001.html>