That is a work which has been discussed couple years ago. Basically, the project system has already cached the disk state (to detect file system changes to reevaluate it when new files are added), and if we can share the disk state to the msbuild through the evaluation context, the logic in msbuild to resolve file globbings would be able to resolve them based on in-memory state, instead of scanning the disk again.
This is not only to reduce IO during the solution loading time, also, it ensure the correctness of the project system. Today, the project system monitor the file system, but doesn't have a good way to align the state with the time msbuild reads the disk state. It leads some temporary files to appear in the project tree.
That is a work which has been discussed couple years ago. Basically, the project system has already cached the disk state (to detect file system changes to reevaluate it when new files are added), and if we can share the disk state to the msbuild through the evaluation context, the logic in msbuild to resolve file globbings would be able to resolve them based on in-memory state, instead of scanning the disk again.
This is not only to reduce IO during the solution loading time, also, it ensure the correctness of the project system. Today, the project system monitor the file system, but doesn't have a good way to align the state with the time msbuild reads the disk state. It leads some temporary files to appear in the project tree.