[racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might

At least, as far as I can tell, it does not perform any better than the
splay tree.  It's actually about a second slower when indenting
drracket/private/unit.rkt.  Darn it.


However, I did find something that's slightly nutty: the following patch
appears to greatly improve indentation:


https://github.com/dyoo/racket/commit/36670d335d72bb164f3e5dbd97763d69664337a2


This crazy code is motivated by the following snippets from the profiler,
when a profile call is wrapped around tabify-selection:


------------------------------------------------------------------------------------------------------------
                                  loop [34]
                            0.1%
                                  get-backward-sexp method in
...k/private/racket.rkt:425:2 [28]       99.9%
 [37] 50648(61.1%)     0(0.0%)  stick-to-next-sexp? method in
...k/private/racket.rkt:425:2 ...
                                  do-forward-match method in
...rk/private/color.rkt:71:2 [50]         99.9%

...

------------------------------------------------------------------------------------------------------------
                                  get-forward-sexp method in
...k/private/racket.rkt:425:2 [38]        17.1%
                                  stick-to-next-sexp? method in
...k/private/racket.rkt:425:2 [37]     82.9%
 [50] 61043(73.6%)    53(0.1%)  do-forward-match method in
...rk/private/color.rkt:71:2 ...
                                  colorer-driver method in
...rk/private/color.rkt:71:2 [66]           99.8%
                                  match-forward method in paren-tree% [72]
                             0.1%
------------------------------------------------------------------------------------------------------------


If I'm reading the profiler output correctly, this is saying that 61% of
the time is being spent in stick-to-next-sexp?, and that in
stick-to-next-sexp?, the majority of the time goes through
do-forward-match.  In the diff above, I made the code speculatively match
the text: if it fails, there's no need to call do-forward-match.  I
reasoned that it looked expensive to call: maybe we can avoid it in the
common case.

I'm seeing indentation times cut by 50%; I've been staring at this all day,
so I don't trust myself yet.  Can anyone else confirm that that they see a
similarly dramatic improvement in tabification when this hack is in place?


I have not committed this yet because it's kludgy code.  :)  I know the
above is not quite the right way to solve the problem, but it seems like it
would be worthwhile to do something like this.  Of course, it would be
better to fix forward-match so it isn't so expensive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121125/1ad1dc73/attachment.html>