Performance Price Payment

High-level languages and declarative models make it less obvious what performance costs come with their usage. For example in SQL, it's hard to even make an educated guess without knowing about the indexes available to the DBMS, much less considering what other activity might be taking place on the server. It's also easy to make expensive mistakes when developing an application, and get cross-product oopsies (easy to notice) or create unnecessary / inefficient work (harder to notice).

Another example that may fall in this bucket is the usage of strings in the .NET Framework. Building long strings by appending with multiple += operator invocations is expensive compared to using StringBuilder to perform an equivalent job - but this not at all obvious from reading the code with little understanding of how it's implemented (or, rather, 'how the implementation performs').

In Windows Presentation Foundation, an example I can think of is the use of TextBlock vs. TextFlow. In most scenarios, using TextBlock will be more efficient for small amounts of text (think of labels, menu items, buttons, etc), whereas TextFlow will have better performance for larger amounts of text (documents, long help entries and the like).

Maybe the one takeaway (that smells an awful lot like a cop-out, I know) is measure, measure, measure.

This posting is provided "AS IS" with no warranties, and confers no rights.