Jeremie Pelletier wrote:
The IDE usually keeps the files in memory and could therefore just call
something like getSemantics(char** fileBuffers, int* fileSizes, int
nFiles, ParseNode* parseTree) and have its parse nodes already allocated
in process memory ready for use.
Considering a lot of IDEs like to re-parse the current file every time
the keyboard is idle for a few seconds, this could really help
performance, nothing is more annoying than an IDE that feels unresponsive.
I understand and agree, but we are operating under severe manpower
constraints. I don't have a 100 million dollar budget! (I'm sure MS
spends more than that on VS.)
You're certainly welcome to take the compiler front end and try and make
a dll out of it or integrate it directly into an IDE. But what I
suggested would probably get a lot of results for a minimal investment
in the front end and a minimal investment in existing IDEs.
My experience with making responsive interactive apps on slow machines
suggests that using a multithreaded approach would make the IDE
responsive even if the underlying parsing process is slow. What you do
is, every time the source file changes, fire off a background thread at
a low priority to reparse. If the source changes before it finishes,
restart that thread. When the IDE actually needs the results, it uses
the results of the most recently finished parse.
With this approach, there won't be any hangs where the keyboard is
unresponsive.
Experience also suggests that using fork/exec rather than a shared dll
approach is much more robust and easier to develop. The reason is that
the former uses separate processes, which cannot step on each other. The
latter puts everything in one process space, where you've got all the
lovely, time-consuming, hair-pulling concurrency problems. The utter
failure of the parse process also cannot bring down the IDE.
