[racket-dev] More Scribble optimization; contracts?

I think the contracts on struct accessors (and specifically in
scribble core data structures) is significant. If you have ideas on
how to speed them up, that'd be welcome. I think they are set up to be
easily disabled (they are added with a macro somewhere) so you can
time things if you want.

FWIW, those contracts have been helpful to me on numerous occasions so
I would object to simply removing them. But it seems like there could
be some clever thinking that would help us pay the price when running
scribble docs.

On Fri, Nov 9, 2012 at 7:17 PM, Danny Yoo <dyoo at hashcollision.org> wrote:
> I've been hammering on the problem of speeding up scribble.  One of the
> things that's a surprise is that the contract checks on the part/element
> structure appear to be significant because Scribble documents are so
> granularly structured.
>
> I focus on extract-part-style-files in scribble/base-render.rkt, which is
> called on the entire part structure to collect information on what style
> files are mentioned in the document.  On my system, when running Scribble on
> reference.scrbl, it took about 1.2 seconds for a single call to
> extract-part-style-files.  This made me blink: extract-part-style-files
> should just be a simple, linear walk through the tree structure to look for
> style file declarations (modulo dealing with delayed, traverse, and
> part-relative blocks, which look more complicated).
>
> The contract checks appear to take a significant chunk of that time.  I've
> judiciously added a few unsafe accessors, and the runtime of
> extract-part-style-files goes down from 1.2 seconds to 800 milliseconds.
> That is, about 400 milliseconds, or 30% of the time of
> extract-part-style-files, is dedicated to contract checking alone.  My hack
> is up here:
>
>     https://github.com/dyoo/racket/tree/scribble-speed
>
> I haven't pushed these optimizations upstream yet because I'd like a review
> to see if this is actually the right way to approach this particular
> problem.
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>