Improved efficiency?

DanEssin posted on Sunday, July 30, 2006

This routine  from  BusinessBase gets called alot (especially if you are binding.  It seems to me that it would be slightly more efficient to  not  keep allocating a variable just to return "" so I'm suggesting the following change for comment.

    string IDataErrorInfo.this[string columnName]
    {
      get
      {
        //string result = string.Empty;
        if (!IsValid)
        {
          Validation.BrokenRule rule =
            ValidationRules.GetBrokenRules().GetFirstBrokenRule(columnName);
          if (rule != null)
              return rule.Description;
          else
              return string.Empty;
        }
        else
            return string.Empty;
      }
    }

RockfordLhotka replied on Sunday, July 30, 2006

Though I'll be the first to admit that I'm very inconsistent on this point, I do try to follow the best practice of having a single point of exit from each method.

Yes, you can find lots of places where I don't do this - but that's my bad in terms of consistency...

The real challenge here is that you can't tell whether there's any gain at all from what you propose. Even if you look at the IL and find that it didn't already optimize the code, the JIT compiler may very well optimize that code.

I still remember this program I wrote in VAX FORTRAN many, many years ago, which was entirely optimized away by the compiler. It managed to detect that I wasn't using the output of the app (which was true - it was a timing test for performance) and so it decided that none of the code in the app was needed and it generated just a single line of assembly output: .END

DanEssin replied on Sunday, July 30, 2006

Fortunately the Fortran compiler on the PDP-11 wasn't that "smart". We never did manage to get expenditure authority for a VAX. Instead we eventually go a Pick system running on a 68000 which we eventually ported to Advanced Pick over SCO Unix at a P90 Compaq. It's still in production supporting 30 users in 64K of memory. I guess all optimization is relative :)

Given that, a single exit point may be a more useful goal than trying to save one allocation that you can't even be sure is occurring.

RockfordLhotka wrote:

Though I'll be the first to admit that I'm very inconsistent on this point, I do try to follow the best practice of having a single point of exit from each method.

Yes, you can find lots of places where I don't do this - but that's my bad in terms of consistency...

The real challenge here is that you can't tell whether there's any gain at all from what you propose. Even if you look at the IL and find that it didn't already optimize the code, the JIT compiler may very well optimize that code.

I still remember this program I wrote in VAX FORTRAN many, many years ago, which was entirely optimized away by the compiler. It managed to detect that I wasn't using the output of the app (which was true - it was a timing test for performance) and so it decided that none of the code in the app was needed and it generated just a single line of assembly output: .END