joshnorton wrote:Do you think it would be hard to get the best of both worlds and have the type scanning happen on a background thread, and have the type definitions be persisted across solution loads?
It might be possible to improve it but it won't be error prone. Suppose I introduce a concept of "stale" cache items. Instead on getting rid on cached files info on project removal, I'd make them stale and keep around. I could then add them back w/o re-scanning when project's added back to the solution.
It gets tricky when say you have a second class added to one of the stale files. Unless I re-scan the file right away when project's being added, I won't see the new class. The good thing is that DPack's cache is self-correcting. If file is not supposed to be there, it's deleted on next project load. When file being opened hasn't been scanned yet, it's re-scanned once.
As far as scanning of new projects on the main thread vs. in the background, that was done intentionally. Due to VS extensibility and COM performance issues, major re-scans like the initial scan and project added event must be done on the main thread. Everything else is pushed onto the secondary thread. The performance improvements you seeing in this version is the result of that approach.