Profiling - Don't (Over)do It

When in the course of a large deployment of an enterprise application, I've seen many a developer quick to break out their favorite profiling tools (e.g., OptimizeIt, JProfiler, etc.) and 'get to the bottom' of the performance problems. And they do get to the bottom, often way too far down there (think seeing only those proverbial trees as opposed to the forest). The problem is that all too often, this results in some low-level slight optimization of some oft-called function, not a real examination of higher level architectural issues that could really speed things up if fixed. Shaving a millionth of a second off of a few functions called tens of thousands of times is often not particularly helpful. Restructuring code to cache significantly more in memory that was previously in DB, for example, probably will be (although of course brings with it various irritating issues related to caching). But you will not get such suggestions of restructing from profilers of course. Very often in enterprise apps, the issue is not computing a value or concatenating some long string or what-have-you, it's too many roundtrips to someplace else far, far away.