В данном конкретном случае два фактически идентичны. Компилятор преобразует второй вариант, использующий оператор +
, в вызов Concat, первый вариант.
Ну, то есть, если две действительно содержат строковые переменные, которые были объединены.
Этот код:
B = "abc" + "def";
фактически превращается в это, без объединения вообще:
B = "abcdef";
Это можно сделать, потому что результат сложения может быть вычислен во время компиляции, поэтому компилятор делает это.
Однако, если бы вы использовали что-то вроде этого:
A = String.Concat(stringVariable1, stringVariable2);
B = stringVariable1 + stringVariable2;
Тогда эти два сгенерируют один и тот же код.
Однако я хотел бы точно знать, что сказали эти «многие», так как я думаю, что это что-то другое.
Я думаю, что они сказали, что конкатенация строк плохая, и вы должны использовать StringBuilder или подобное.
Например, если вы сделаете это:
String s = "test";
for (int index = 1; index <= 10000; index++)
s = s + "test";
Затем происходит то, что для каждой итерации цикла вы создаете одну новую строку и позволяете старой получить право на сборку мусора.
Кроме того, в каждой такой новой строке будет скопировано все содержимое старой, что означает, что вы будете перемещать большой объем памяти.
Принимая во внимание следующий код:
StringBuilder sb = new StringBuilder("test");
for (int index = 1; index <= 10000; index++)
sb.Append("test");
Вместо этого будет использоваться внутренний буфер, который больше, чем нужно, на тот случай, если вам нужно добавить в него больше текста. Когда этот буфер заполнится, будет выделен новый, больший, а старый оставлен для сборки мусора.
Таким образом, с точки зрения использования памяти и использования процессора, последний вариант намного лучше.
Кроме этого, я бы старался избегать чрезмерного сосредоточения на том, "является ли вариант кода X лучше Y", помимо того, что у вас уже есть. Например, сейчас я использую StringBuilder только потому, что знаю об этом деле, но это не означает, что весь код, который я пишу, использующий его, действительно нуждается в этом.
Старайтесь не тратить время на микрооптимизацию своего кода, пока не поймете, что у вас есть узкое место. В это время обычный совет по поводу меры сначала, вырезанный позже, все еще действует.