c# - Reason for 11 overloads of string.Concat -

i noticed there 11 overloads of method string.concat()

public static string concat(ienumerable<string> values); public static string concat<t>(ienumerable<t> values); public static string concat(object arg0); public static string concat(params object[] args); public static string concat(params string[] values); public static string concat(object arg0, object arg1); public static string concat(string str0, string str1); public static string concat(object arg0, object arg1, object arg2); public static string concat(string str0, string str1, string str2); public static string concat(object arg0, object arg1, object arg2, object arg3); public static string concat(string str0, string str1, string str2, string str3); 

what reason that? both

public static string concat(params object[] args); public static string concat<t>(ienumerable<t> values); 

should needed because same convenient/powerful. msdn doesn't give answer on , if remove 9 "duplicate" overloads framework, noone notice.

the primary motivator of implementation decision performance.

as correctly note, there two:

public static string concat(params object[] args); public static string concat<t>(ienumerable<t> values); 

and if c# implemented "params enumerable" feature -- whereby variadic method have ienumerable<t> instead of t[] expanded parameter -- down one. or, lose enumerable overload , use object array version.

suppose did latter. say

string x = foo(); string y = bar(); string z = x + y; 

and happens? in world variadic tostring codegen'd as

string x = foo(); string y = bar(); object[] array = new string[2]; array[0] = x; array[1] = y; string z = string.concat(array); 

so: let's review. presumably calls allocate 1 string each. allocate short-lived array, copy references on it, pass variadic method, etc. method needs written handle array of size, handle null array, , on.

we've not added new short-lived garbage gen 0 heap; we've created 2 new edges in liveness analysis graph might have traversed. may have either decreased amount of time between collections adding pressure, or increased cost of collections adding edges, or, likely, collections become both more frequent , more expensive: double-whammy.

but wait, there's more. must consider implementation of called concat method looks like.

the object array -- surprise -- array of objects, not array of strings. need do? callee needs convert each string. calling tostring on each? no, might crash. checking null first, , calling tostring.

we've passed in strings, callee doesn't know that. tostring identity strings, the compiler doesn't know that, , call virtualized jitter can't optimize away either. we've taken on unnecessary few nanoseconds of checks , indirections. not mention needed check array null, length of array, make loop loop on each element of array, , on.

these expenses very small per concatenation, , add real time spent , memory pressure.

a great many programs have performance gated upon string manipulations , memory pressure. how can eliminate or mitigate these costs?

we observe most string concatenations 2 strings, makes sense create overload handle situation:

static string concat(string, string) 

now can codegen fragment above as:

string x = foo(); string y = bar(); string z = string.concat(x, y); 

now there no array created, there no garbage created, no collection pressure, no new edges in reference graph. in callee, strings need checked nullity don't need call tostring in implementation because have type system enforce operands strings, don't need check array nullity, don't need loop variable being checked against array length, , on.

thus have justification having two overloads: 1 takes params array, , 1 takes 2 strings.

and repeat analysis scenario common , more performant. each additional overload designed produce more efficient alternative common scenario. more common scenarios identified can made faster , less resource intensive, there incentive produce more overloads, , fix compilers generate code takes advantage of these overloads. net result dozen seemingly redundant overloads, each of can tuned high performance; these cover cases commonly seen in real programs.

if subject interests you, i've written short series of articles on how redesigned string concatenation optimizer in 2006.

https://ericlippert.com/2013/06/17/string-concatenation-behind-the-scenes-part-one/