UPDATE
Следуя Mr Cheese answer, кажется, что
public static string Join<T>(string separator, IEnumerable<T> values)
перегрузка string.Join
получает свое преимущество от использования класса StringBuilderCache
.
Есть ли у кого-нибудь отзывы о правильности или причине этого заявления?
Могу ли я написать свой собственный,
public static string Join<T>(
string separator,
string prefix,
string suffix,
IEnumerable<T> values)
которая использует класс StringBuilderCache
?
После отправки моего ответа на этот вопрос я был вовлечен в какой-то анализ, который будет лучшим ответом.
Я написал этот код в консольном классе Program
для проверки своих идей.
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
class Program
{
static void Main()
{
const string delimiter = ",";
const string prefix = "[";
const string suffix = "]";
const int iterations = 1000000;
var sequence = Enumerable.Range(1, 10).ToList();
Func<IEnumerable<int>, string, string, string, string>[] joiners =
{
Build,
JoinFormat,
JoinConcat
};
// Warmup
foreach (var j in joiners)
{
Measure(j, sequence, delimiter, prefix, suffix, 5);
}
// Check
foreach (var j in joiners)
{
Console.WriteLine(
"{0} output:\"{1}\"",
j.Method.Name,
j(sequence, delimiter, prefix, suffix));
}
foreach (var result in joiners.Select(j => new
{
j.Method.Name,
Ms = Measure(
j,
sequence,
delimiter,
prefix,
suffix,
iterations)
}))
{
Console.WriteLine("{0} time = {1}ms", result.Name, result.Ms);
}
Console.ReadKey();
}
private static long Measure<T>(
Func<IEnumerable<T>, string, string, string, string> func,
ICollection<T> source,
string delimiter,
string prefix,
string suffix,
int iterations)
{
var stopwatch = new Stopwatch();
stopwatch.Start();
for (var i = 0; i < iterations; i++)
{
func(source, delimiter, prefix, suffix);
}
stopwatch.Stop();
return stopwatch.ElapsedMilliseconds;
}
private static string JoinFormat<T>(
IEnumerable<T> source,
string delimiter,
string prefix,
string suffix)
{
return string.Format(
"{0}{1}{2}",
prefix,
string.Join(delimiter, source),
suffix);
}
private static string JoinConcat<T>(
IEnumerable<T> source,
string delimiter,
string prefix,
string suffix)
{
return string.Concat(
prefix,
string.Join(delimiter, source),
suffix);
}
private static string Build<T>(
IEnumerable<T> source,
string delimiter,
string prefix,
string suffix)
{
var builder = new StringBuilder();
builder = builder.Append(prefix);
using (var e = source.GetEnumerator())
{
if (e.MoveNext())
{
builder.Append(e.Current);
}
while (e.MoveNext())
{
builder.Append(delimiter);
builder.Append(e.Current);
}
}
builder.Append(suffix);
return builder.ToString();
}
}
запуск кода в конфигурации выпуска, построенный с оптимизацией, из командной строки я получаю такой вывод.
...
Время сборки = 1555 мс
Время JoinFormat = 1715 мс
Время присоединения = 1452мс
Единственный сюрприз здесь (для меня) заключается в том, что комбинация Join-Format является самой медленной. Рассмотрев этот ответ, это имеет немного больший смысл, вывод string.Join
обрабатывается внешним StringBuilder
в string.Format
, существует задержка с этим подходом.
После размышлений я не понимаю, как string.Join
может быть быстрее. Я читал о его использовании FastAllocateString()
, но я не понимаю, как буфер можно точно предварительно выделить без вызова .ToString()
для каждого члена sequence
. Почему комбинация Join-Concat работает быстрее?
Как только я это понимаю, можно ли написать собственную функцию unsafe string Join
, которая принимает дополнительные параметры prefix
и suffix
, а out выполняет "безопасные" альтернативы.
У меня было несколько попыток, и пока они работают, они не быстрее.