On Thursday, February 11, 2016 at 3:08:16 PM UTC, Matthias Felleisen wrote:
> On Feb 10, 2016, at 4:58 PM, stef wrote:
>
> > Typed Racket has similar huge performance problems, so I'm actually
> > worried about fundamental limitations of Racket as a host.
>
>
> I am sorry but I take offense here. What could that even remotely mean? --
> Matthias
Sorry, apparently that paragraph somehow come out all antagonistic. Let me try
again. :)
Racket has prominent tools for debugging and profiling run-time code, as you'd
expect. It's also designed for implenenting languages, which involves a lot of
compile-time code. So I'd expect there to be similar tools for it, and of
course the macro stepper for example is right there in DrRacket.
So I'm really confused how opaque macro performance is.
Concretely, I tried out two non-trivial macro-heavy tools (TR and nanopass),
both of which currently very badly affect compilation times of modules that use
them. Of course particularly in the case of nanopass, it's likely that it's
just doing something silly, partially do to being a Chez scheme port.
But I wanted to make clear that I'm specifically not asking "how do I fix
nanopass", but "how do I measure what's going on at compile-time".
I did get this to run:
(require profile)
(profile (dynamic-require "./c.rkt" #f))
but that's still very opaque:
- It seems to only account for ~10% of the runtime. I tried increasing the
sampling rate, but that seems to have little effect. Are there limitations as
to what it can sample?
- Is there a tracing profiler? If I enable errortrace, there just isnt't a
breakdown at all! Does errortrace not work at compile-time? What does?
- There is no memory profile. Is that a general limitation of (profile)? How do
I get one?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
