...here's the project file for my question

Also, I'm running in Atmel Studio 7

I've downloaded yesterdays build and that appears to have fixed it. That's great, thanks, it was becoming a right pain!

Your system appears to be working correctly but your pc is struggling for some reason. It is correct that if a file changes that contains #includes the #includes are re-parsed.

You did not respond to my question about compilation in the arduino ide. First build should be long, subsequent build faster? How long?

You might need to ensure that your file>preferences>sketchbook folder is set to your one drive if you changed that in visual micro.

Also ensure the file>preferences>board urls match the ones in Visual Micro IDE Location > Board urls.

In essance the options you set in Visual Micro can be set in the Arduino IDE. Visual Micro will use same or allow you to override/append.

Thanks for the files. It's not a release issue ...

The build in arduino ide and visual micro are identical except that visual micro also copies the build output up to the project release/debug folders because that option is enabled.

The arduino ide had previously compiled the core and it is also possible you have enabled high cache in the file>preferences at some previous time or had previously built for the esp32dev in the arduino ide. This simply means it already had  cached core.

Both IDE's are using the same Temp folder location and both are discovering the same libraries.

The arduino ide does same deep search as visual micro it is shown as "discovering libraries" in the arduino output. You can not switch off deep search in te arduio ide.

Deep search will always run through the file that has changed to detect #include for which it can select the correct library. If a library has previouly been compiled that has no bearing on deep search attempting to detect which libs the code is using.

Deep search honors conditional #if statements therefore any change of code can change of an #include is now valid or not. It is possible to have #includes that should be ignored because the #if condition fails therefore deep seach needs to re-run against the code. It is annoying that the GCC-E system we all use for deep search notifies only one #include at a time. Therefore we have to run once for each discovered #include.

Switching off deep search means tht we use a faster less capable system to discover #includes in .ino code. The faster system can not determine if an #include is conditional or not. The deep search also searches the source code of discovered libraries to see if a library is required that has not been #included by the user in the project code. Therefore you need to ensure all required libs have an #include in the .ino code so that the library can be discovered.

Your pc performance is at least 5 times slower than normal and possibly an issue with the virtual machine. If you look at the build output you will see that we just run .exe files to build each file and to link etc. You can grab any one of those .exe command lies and paste into cmd.exe or a .bat file. Then run, that is what is slow for you. 

For me the .ino code below compiles in 9.6 seconds 2nd time with deep search enabled (after adding a method and saving).

Sorry to say it is nothing to do with arduino or visual micro otherwise we could fix something. I am using the slightly newer (latest) esp32 core from board manager but I checked against the version you are using the tool chain .exe's look to be same.

#include <SPIFFS.h>
#include <vfs_api.h>
#include <FSImpl.h>
#include <FS.h>
#include <ArduinoJson.hpp>
#include <ArduinoJson.h>
#include <SPI.h>
#include <Adafruit_SSD1306.h>
#include <gfxfont.h>
#include <Adafruit_SPITFT_Macros.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_GFX.h>
void setup() {

}

// the loop function runs over and over again until power down or reset
void loop() {

}