cameron314 added a comment. We did profile at one point, to see if it was something we could trivially speed up (it wasn't). Most of it was on the parsing/annotation side, yes (which makes sense, since that's the majority of the work when the format region itself is limited). I'm afraid I don't recall more details (this was a few months ago after we had just started). The memory usage spikes significantly, too. Anyway, we didn't want the size of the file to affect the insertion time of a semicolon if at all possible.
All of our optimization boils down to only giving ClangFormat the minimum amount of code necessary to format the statement or block we want. The way we determine this context is almost certainly not something you want to see in ClangFormat :-) It's quite heuristic in some places, and is very specific to C/C++. Sometimes it will even bail out and not format anything if the context spans too many (e.g. 2000+) lines. There's multiple levels of context involved, too (e.g. when declaration alignment is on, adjacent statements that look like declarations are also included in the context to get things to line up). And fake braces to set up the indentation correctly. It's also all written in C#, leveraging a large body of existing parsing code that we'd already written (for features like smart indent); things taken for granted in the IDE, like O(1) access to the tokens that make up a given line (which is constantly maintained as the user types instead of having to reparse from the top of the file), are simply not possible to do as efficiently in ClangFormat (barring persistent caching between calls, which of course is a whole can of worms in itself). Anyway, all that stuff is very "porcelain-y" code (to borrow a term from the git developers) that would no doubt vary significantly from IDE to IDE. http://reviews.llvm.org/D19031 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
