Project system integration with version control - please don't optimize too much!

Motto for today is:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

Visual Studio 2010 was significant for TFS version control for many reasons (biggest being probably schema change), but one that every one in the division was paying attention was that we became the default scc provider. So whatever perf tests were run (and we were running a lot of them) it was hitting tfs scc provider. In different points in time different project system groups were realizing that calling GetSccGlyph is not optimized for not source controlled projects and takes some significant amount of time (I think 15% when loading C# project). They also realized that in those cases, GetSccGlyph is a no-op. You may see where it is going :) Of course project system knows the bindings that are stored in it, because it's passing them to the RegisterSccProject call. So as you can imagine, obvious solution was to bypass calling GetSccGlyphs if there are no bindings.

Surprisingly tfs is not a victim in this story. We add bindings as soon as project is added to source control and we keep them forever (or until you remove them). However some scc providers don't use bindings at all (one of the providers for Source Depot) or save them lazily (e.g. on checkin - VSS). In that case, they won't be called and no glyphs will be displayed. In some cases the provider may depend even more on GetSccGlyph calls and other functionality will be broken as well.

Solution: rollback changes to the project systems and make GetSccGlyph in tfsprovider very, very fast. Please don't cut public calls just because it works with one scc provider!