5 hours ago, Danny Yoo wrote:
> Somewhat small change. But it was low-hanging fruit, and I needed
> to make some kind of progress. :)
Last time I benchmarked this kind of IO, using `write-string' and/or
`write-bytes' was even faster (and they "feel right" for this kind of
optimization work). Another thing to try, though not a low hanging
thing, is to see how the output of `scribble/html' compares to this --
it's undocumented, still, but I vaguely want to try moving the
scribble rendering to it.
> The place where Scribble documentation generation uses a lot of time
> appears to be the evaluations that feed @interactions. (I have some
> ideas on pushing the computation for @interactions off to
> compile-time, but haven't cooked and taste-tested the ideas yet.)
This time is spent on the sandboxes. Like Robby, I don't think that
there will be any benefit to doing the work at compile time -- the
setup process re-runs files only when needed, and that happens when
they need to be recompiled, so you end up doing the same work at the
same time.
My guess is that you can try to speed things up with some of these:
* Try to initiate a smaller sandbox, like switching from a `racket'
sandbox to a `racket/base' one.
* Try to tweak the sandbox namespace specs to share many modules with
the calling environment, so they don't need to be reinstantiated
over and over.
* Possibly try to see if there's some way to share and re-use
sandboxes in different docs, instead of making up new ones. This
might apply to some sandboxes that don't change state in a way that
can leak out to other such boxes, and my guess is that many of them
are in this category. This might be dangerous though, if such a
file is later changed to make a change to the environment which can
affect the next client.
> There's a surprising amount of time spent turning the part/element
> structure into the xexprs (about 9 seconds), and I was going to look
> into that next.
This might be better with the scribble/html that I mentioned. (Did I
mention that it's still undocumented?) The structures that it uses
are generally much more forgiving, and I actively tried to avoid
avoidable speed losses.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
