Использование метода StringBuilder Remove более эффективно, чем создание нового StringBuilder в цикле?

Вариант 2 должен (я считаю) фактически превзойти Вариант 1. Акт вызова Remove "заставляет" StringBuilder взять копию строки, которую он уже вернул. Строка фактически изменчива в StringBuilder, и StringBuilder не принимает копию, если это не нужно. С опцией 1 он копирует, прежде чем в основном очистить массив - с опцией 2 копирование не требуется.

единственным недостатком варианта 2 является то, что если строка заканчивается длинным, будет несколько копии, сделанные во время добавления, в то время как вариант 1 сохраняет исходный размер буфера. Однако, если это произойдет, укажите начальную емкость, чтобы избежать дополнительного копирования. (В вашем примере кода строка будет больше, чем 16 символов по умолчанию - инициализация ее с емкостью, скажем, 32 уменьшит необходимые дополнительные строки.)

помимо производительности, однако, вариант 2 просто чище.

в то время как ваше профилирование, вы также можете попробовать просто установить длину StringBuilder в ноль при входе в цикл.

formattedOutput.Length = 0;

поскольку вас интересует только память, я бы предложил:

foreach (string outputString in outputStrings)
    {    
        string output = "prefix " + outputString + " postfix";
        ExistingOutputMethodThatOnlyTakesAString(output)  
    }

переменная с именем output имеет тот же размер в исходной реализации, но другие объекты не нужны. StringBuilder использует строки и другие объекты внутри, и вы будете созданы много объектов, которые должны быть GC'D.

обе строки из Варианта 1:

string output = formattedOutput.ToString();

и строка из Варианта 2:

ExistingOutputMethodThatOnlyTakesAString(
           formattedOutputInsideALoop.ToString());

создать неизменяемые объект со значением префикса + outputString + postfix. Эта строка одинакового размера независимо от того, как вы ее создаете. То, что вы действительно спрашиваете, является более эффективной памятью:

    StringBuilder formattedOutput = new StringBuilder(); 
    // create new string builder

или

    formattedOutput.Remove(0, output.Length); 
    // reuse existing string builder

пропуск StringBuilder полностью будет более эффективной памятью, чем любой из вышеперечисленных.

Если вам действительно нужно знать, какой из двух более эффективен в вашем приложении (это, вероятно, будет зависеть от размера вашего списка, префикса и outputStrings) я бы рекомендовал профилировщик муравьев red-gatehttp://www.red-gate.com/products/ants_profiler/index.htm

Джейсон

ненавижу это говорить, но как насчет тестирования?

этот материал легко узнать самостоятельно. Запуск Системного Монитора.exe и добавьте счетчик для коллекций .NET Memory + Gen 0. Запустите тестовый код миллион раз. Вы увидите, что для опции №1 требуется половина количества коллекций, необходимых опции № 2.

мы говорил об этом раньше с Java, вот результаты [Release] версии C#:

Option #1 (10000000 iterations): 11264ms
Option #2 (10000000 iterations): 12779ms

Update: в моем ненаучном анализе, позволяющем выполнять два метода при мониторинге всех счетчиков производительности памяти в perfmon, не привело к какой-либо заметной разнице с любым методом (кроме того, что некоторые счетчики всплеск только во время выполнения любого теста).

и вот что я тест:

class Program
{
    const int __iterations = 10000000;

    static void Main(string[] args)
    {
        TestStringBuilder();
        Console.ReadLine();
    }

    public static void TestStringBuilder()
    {
        //potentially a collection with several hundred items:
        var outputStrings = new [] { "test1", "test2", "test3" };

        var stopWatch = new Stopwatch();

        //Option #1
        stopWatch.Start();
        var formattedOutput = new StringBuilder();

        for (var i = 0; i < __iterations; i++)
        {
            foreach (var outputString in outputStrings)
            {
                formattedOutput.Append("prefix ");
                formattedOutput.Append(outputString);
                formattedOutput.Append(" postfix");

                var output = formattedOutput.ToString();
                ExistingOutputMethodThatOnlyTakesAString(output);

                //Clear existing string to make ready for next iteration:
                formattedOutput.Remove(0, output.Length);
            }
        }
        stopWatch.Stop();

        Console.WriteLine("Option #1 ({1} iterations): {0}ms", stopWatch.ElapsedMilliseconds, __iterations);
            Console.ReadLine();
        stopWatch.Reset();

        //Option #2
        stopWatch.Start();
        for (var i = 0; i < __iterations; i++)
        {
            foreach (var outputString in outputStrings)
            {
                StringBuilder formattedOutputInsideALoop = new StringBuilder();

                formattedOutputInsideALoop.Append("prefix ");
                formattedOutputInsideALoop.Append(outputString);
                formattedOutputInsideALoop.Append(" postfix");

                ExistingOutputMethodThatOnlyTakesAString(
                   formattedOutputInsideALoop.ToString());
            }
        }
        stopWatch.Stop();

        Console.WriteLine("Option #2 ({1} iterations): {0}ms", stopWatch.ElapsedMilliseconds, __iterations);
    }

    private static void ExistingOutputMethodThatOnlyTakesAString(string s)
    {
        // do nothing
    }
} 

Вариант 1 в этом сценарии немного быстрее, хотя вариант 2 легче читать и поддерживать. Если вы не выполняете эту операцию миллионы раз спина к спине, я бы придерживался варианта 2, потому что я подозреваю, что Вариант 1 и 2 примерно одинаковы при запуске в одной итерации.

Я бы сказал, вариант №2, Если определенно более простой. С точки зрения производительности, звучит как то, что вам просто нужно проверить и увидеть. Я бы предположил, что это не имеет достаточного значения, чтобы выбрать менее простой вариант.

Я думаю, что Вариант 1 будет чуть больше эффективно, как новый объект не создается каждый раз. Сказав это, GC делает довольно хорошую работу по очистке ресурсов, как в Варианте 2.

Мне кажется, вы можете попасть в ловушку преждевременной оптимизации (корень всего зла -- кнут). Ваш IO займет гораздо больше ресурсов, чем строковый конструктор.

Я склонен идти с более ясным / более чистым вариантом, в этом случае вариант 2.

Роб

1. измерения
2. предварительно выделите как можно ближе к тому, сколько памяти вам понадобится
3. Если скорость-ваше предпочтение, то рассмотрите довольно прямой многопоточный фронт до середины, от середины до конца параллельный подход (разверните разделение труда по мере необходимости)
4. измерить его снова

что важнее тебя?

2. скорость

3. ясность