Another “just links” entry… I thought that Raymond’s entry on the performance shell game was particularly good, and Michael’s additional take was very relevant. Much of performance work involves shifting work around from scenario to scenario, and when doing so it is vitally important that you keep track of the bigger picture. The fact that it’s not possible to test every scenario can easily lead to tunnel vision, where you get so motivated to improve one important scenario (application startup) that you lose sight of perhaps an even more important scenario (OS startup) that’s “not your department,” but which impacts users all the same…
I’ve been playing the startup-performance game quite a lot lately. The biggest culprits I’ve found are the System.Data and System.XML namespaces, which from a startup and general performance perspective, are the very incarnation of evil itself.
And it doesn’t help that the VS.NET IDE *insists* I need a reference to System.Data everytime I add a form/control to a project. Not everyone out here is writing yet another boring DAL, so I hope this "feature" will be fixed in VS 2005.