At least, as far as I can tell, it does not perform any better than the splay tree.  It&#39;s actually about a second slower when indenting drracket/private/unit.rkt.  Darn it.<div><br><div><br></div><div>However, I did find something that&#39;s slightly nutty: the following patch appears to greatly improve indentation:</div>

<div><br></div><div>    <a href="https://github.com/dyoo/racket/commit/36670d335d72bb164f3e5dbd97763d69664337a2">https://github.com/dyoo/racket/commit/36670d335d72bb164f3e5dbd97763d69664337a2</a></div><div><br></div><div>

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

<div>                                  loop [34]                                                             0.1%</div><div>                                  get-backward-sexp method in ...k/private/racket.rkt:425:2 [28]       99.9%</div>

<div> [37] 50648(61.1%)     0(0.0%)  stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 ...</div><div>                                  do-forward-match method in ...rk/private/color.rkt:71:2 [50]         99.9%</div>

</div><div><br></div><div>...</div><div><br></div><div>------------------------------------------------------------------------------------------------------------</div></div><div>                                  get-forward-sexp method in ...k/private/racket.rkt:425:2 [38]        17.1%</div>

<div><div>                                  stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 [37]     82.9%</div><div> [50] 61043(73.6%)    53(0.1%)  do-forward-match method in ...rk/private/color.rkt:71:2 ...</div>

<div>                                  colorer-driver method in ...rk/private/color.rkt:71:2 [66]           99.8%</div><div>                                  match-forward method in paren-tree% [72]                              0.1%</div>

</div><div><div>------------------------------------------------------------------------------------------------------------</div></div><div><br></div><div><br></div><div>If I&#39;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&#39;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.</div>

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

<div><br></div><div><br></div><div>I have not committed this yet because it&#39;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&#39;t so expensive.</div>

</div>