Stringbuilder в foreach медленнее, чем в for, и String.Join () сосет по коллекциям? - PullRequest
3 голосов
/ 02 мая 2011

Увидев здесь вопрос о SO, о присоединении строк, я провел некоторое тестирование и пришел к выводу, что присоединение строки в foreach происходит медленнее, чем с помощью цикла for и использования индексов в массиве.Разве цикл for не должен быть медленнее из-за проверки границ массива?(проверка границ для строк [i], которых нет в foreach).

Еще одна вещь, которую я не понимаю, это string.Join () медлительность в списках ...

РЕДАКТИРОВАТЬ: Обновленоошибка и обновление источника до конечного источника (удаление последнего ",")

Вот результат теста:

DEBUG:
   AMD PHENOM II X4 3GHZ
    StringBuilder foreach System.Action Time: 4077ms (12025926)
    StringBuilder for System.Action Time: 4032ms (11895082)
    String.Join System.Action Time: 5338ms (15744918)
   INTEL XEON W3503 @ 2.4GHZ / 12GB DDR3
    StringBuilder foreach System.Action Time: 4661ms (10926950)
    StringBuilder for System.Action Time: 4202ms (9849590)
    String.Join System.Action Time: 6466ms (15156149)

RELEASE:
   AMD PHENOM II X4 3GHZ
    StringBuilder foreach System.Action Time: 3897ms (11496978)
    StringBuilder for System.Action Time: 3719ms (10970899)
    String.Join System.Action Time: 5307ms (15655162)
   INTEL XEON W3503 @ 2.4GHZ / 12GB DDR3
    StringBuilder foreach System.Action Time: 4533ms (10625128)
    StringBuilder for System.Action Time: 4168ms (9770765)
    String.Join System.Action Time: 7173ms (16813036)
    (why in the world xeon slower than in debug with string.join?)

FOR A GOOD LAUGH LOOK AT THE END.

А вот источник:

public static void Main(string[] Args)
{
    List<string> strings = new List<string>() {};
    for (double d = 0; d < 12000; d++) {
        strings.Add(d.ToString());
    }

    GC.Collect();
    GC.WaitForPendingFinalizers();

    Performance(() =>
    {
            StringBuilder sb = new StringBuilder();
            foreach (string s in strings)
            {
                sb.Append(s);
                sb.Append(",");
            }
            sb.Remove(sb.Length - 1, 1);
    }, "StringBuilder foreach");

    GC.Collect();
    GC.WaitForPendingFinalizers();

    Performance(() =>
    {
        StringBuilder sb = new StringBuilder();
        int max = strings.Count-1;
        int i;
        for (i = 0; i < max; i++)
        {
            sb.Append(strings[i]);
            sb.Append(",");
        }
        sb.Append(strings[i]);
    }, "StringBuilder for");

    GC.Collect();
    GC.WaitForPendingFinalizers();

    Performance(() =>
    {
        string s = string.Join(",", strings);
    }, "String.Join");


}
public static void Performance(Action fn, string prefix)
{
    var timer = new Stopwatch();
    timer.Start();

    for (var i = 0; i < 10000; ++i)
    {
        fn();
    }

    timer.Stop();

    Console.WriteLine("{0} {1} Time: {2}ms ({3})", prefix, fn.ToString(), timer.ElapsedMilliseconds, timer.ElapsedTicks);
}

Строки копируются как типы значений в foreach?Поскольку скорость практически одинакова ...

РЕДАКТИРОВАТЬ:

Чтобы выяснить, почему int max = strings.Count-1; может быть оптимизация вопреки тому, что говорят люди (и тест доказывает, что это):

Мы не работаем с массивами, и коллекция поступает из внешней области видимости в метод, который ее перебирает.Если бы это был strings.Length в цикле for, это могло бы измениться (как другой поток, изменяющий коллекцию) ... но это не причина, причина в том, что мы читаем переменную и не вызываем метод (свойство get) иэто дает только 5% производительности.Это не оптимизация времени компиляции для проверки границ, поскольку никто не может знать заранее значение «max».Это зависит от того, каким будет содержимое строк в каждом вызове метода.

EDIT2:

Был ли тест в выпуске с большей строкой, но с тем же количеством, пожалуйста, посмеяться надString.Join ():

List<string> strings = new List<string>() {};
for (double d = 0; d < 12000; d++) {
    strings.Add("ikugluglizuglkuhiugpiugiugholiugholiughpiuhziuhzuiugloiu" + d.ToString());
}

// AMD PHENOM:
//     StringBuilder foreach System.Action Time: 10080ms (29732687)
//     StringBuilder for System.Action Time: 9659ms (28490593)
//     String.Join System.Action Time: 24509ms (72292291)
// INTEL XEON:
//     StringBuilder foreach System.Action Time: 9790ms (22947294)
//     StringBuilder for System.Action Time: 9140ms (21425490)
//     String.Join System.Action Time: 21114ms (49490839)

Это может быть полезно для массивов, но в коллекциях String.Join отстой, особенно для больших строк!

Просто для справки, если вы хотите сравнить:

Windows 7 64bit
CPU Type    QuadCore AMD Phenom II X4 945
CPU Clock   3000 MHz
L3 Cache    6 MB  (On-Die, ECC, NB-Speed)
North Bridge Clock  2010.8 MHz
Memory 8190 MB
Memory Bus  804.3 MHz DDR3-1600
Motherboard Chipset AMD 790X, AMD K10
Memory Timings  8-9-9-24  (CL-RCD-RP-RAS)
Command Rate (CR)   1T

Ответы [ 2 ]

2 голосов
/ 02 мая 2011

Разве цикл for не должен быть медленнее из-за проверки границ массива?

Нет, CLR может оптимизировать это до 1 проверки, может ли он проверить границы. Что составляет

 int max = strings.Count - 1;

плохая оптимизация. В FX 1.1 это стоило бы вам. (Это тоже неверно).

foreach должен сделать немного больше работы (через Eumerator). Обратите внимание, что разница невелика.

1 голос
/ 05 мая 2011

Посмотрите код IL в ILSpy.

В цикле foreach есть неявная попытка ... наконец, в цикле for нет.

Также внутри foreach есть неявные вызовы MoveNext. MoveNext имеет много накладных расходов, включая проверку изменения версии, прежде чем он, наконец, выполнит операцию индексации в списке, чтобы получить запись.

В теории foreach может быть быстрее, но он явно выполняет больше работы, чем простой цикл for.

Это под vs2010. Не уверен, как другие версии справляются с этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...