Sunday, November 26, 2006

Performance vs. Readability

My pal Rabi recently analyzed Steve McConnell's updated classic Code Complete from a mobile perspective. Personally, I am a huge fan of McConnell's work and credit his books and reading suggestions with tremendously improving my own professional development. However, as Rabi points out, not all suggestions work in all situations.

Among many great points Rabi makes, these two stick out for me:

  1. "So the Compact Framework will pitch code on a per method basis to free memory unlike the full framework."

  2. "Don't have methods just to have more readable code - more code in a method is better"

So how can we as managed (sometimes) mobile developers fight the trade-off of performance vs. readability? Currently, I don't have a good answer. What I do have, however, is a suggestion.

Bring the inline function specifier from C++ to the .NET Compact Framework. MSDN defines inline and __inline as function specifiers that "instruct the compiler to insert a copy of the function body into each place the function is called."

Having the ability to use inline functions would mitigate Rabi's points above. Because code is pitched on a per method basis, the inline code would not be pitched being that the inline code is part of the actual method where it's being used. Additionally, the readability gains from having discrete methods instead of excessively long functions would be there as well.

Another additional benefit would be much easier unit testing. It would be much simpler to unit test these functions by having something like the following:

#if UnitTesting
public int CalculateReturnValue(int param1, int param2, int param3)
private inline int CalculateReturnValue(int param1, int param2, int param3)
... Continue method definition

Therefore, from a testing and readability standpoint the benefit would be had with these methods looking and acting like methods, and from a performance standpoint the benefit would be had with these methods acting like a part of other methods.

No comments: