Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
