I have a class library that is full of typical methods that I use a lot, especially in my domain. Most of this library has remained unchanged for years at this point. More adds than changes.

In the library there's a lot of calling methods within the library - using itself.

From a complete optimization point of view - because this lib is used a lot what makes more sense:

**Use methods within the lib** or **re-write the code within every method** to avoid calling into another method. What's the cost of calling another method or maybe two methods deep versus having the code in the called method.

For instance, this illustrates a common scenario. This method turns what's typically an ugly URL parameter (with encoded html) into a more simple, hackable, date with dashes. So it gets called hundreds of times maybe thousands on a page by hundreds of users (so maybe not a trivial amount of times?). 

The reason I don't think this is pre-optimization or micro optimization (hence why I'm asking) is that since this is a library and is being used by many applications, on the same server, with 100s of users, the "micro" savings could really add up.

```
string GeturlDate(this DateTime date)
{
   return date.GetUrlDate(date, "-");
}
string GetUrlDate(this DateTime date, string delimiter)
{
   return DateHelper.GetUrlDate(date, delimiter);
}

string DateHelper.GetUrlDate(DateTime date, string delimiter)
{
   return string.format("{0}-{1}-{2}", date...);
}

```

In this case, the final method with string.format could be done directly in each of the methods. Avoiding the top most method going two methods in. The first two are extension methods and the last one is a direct call.

Let's skip the overload options (that's used). And while the above is undoubtedly better for maintenance - the last piece of code is in one place, how much more efficient would it be. Does the IL already inline it cause it knows? Is that all handled by the compiler and is not really jumping through methods like one might think?

For complicated functions that could easily introduce errors I would keep one place. 

**EDIT**:
For clarification around the concept of micro-optimizations and why I think thinking about these things is valid. 

* Many times you do not know you have a performance problem - that doesn't mean there isn't one - or one that only rears its head under certain conditions
* There are cases where micro-optimization is used too quickly for "this is the way I've always done it and it works (& there's no perf issues)" instead of considering: "is there a better way to do this" (perhaps under certain conditions)
* Small wins matter for hot paths. A change that results in a 100ns improvement, or less memory consumption, by a factor of 1K or 100K or 1M can result in a perceptible difference.

I think if knowing that writing code a certain way can lead to better "x" then it's a valid consideration and perhaps implementation (especially if you're doing it the first time and not a refactor).

Ultimately, the answers to this question show that amongst other things, what do compiler does and how the BCL itself is written, there's no reason for a change.

Which is good news :)