Причем получится не только читабельнее, но и чуточку быстрее, так как сложение преобразуется в вызов string.Concat(string, string), что быстрее чем создание и использование StringBuilder-а.
Второй пример, на этот раз архитектурного таланта тех же авторов можно поглядеть здесь: Где в МС бурут таких баранов?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>На этот раз подвиг работников Microsoft:
S>Угу, а потом рассказывают мне все что винда оптимизированна
VD>А какая оптимизация!? Ведь буфер до байта рассчитали, чтобы конец строки вместить!
VD>Для тех кто читает с просони поясню, что сей шедевр можно записать так: VD>
VD>Причем получится не только читабельнее, но и чуточку быстрее, так как сложение преобразуется в вызов string.Concat(string, string), что быстрее чем создание и использование StringBuilder-а.
Вообще-то семантика разная
Если строка не пустая, то в 1-м варианте возвращается просто принятая строка без изменений.
Здравствуйте, e-Xecutor, Вы писали:
EX>Вообще-то семантика разная EX>Если строка не пустая, то в 1-м варианте возвращается просто принятая строка без изменений.
Неа. Потому что StringBuilder.Append() и StringBuilder.AppendLine() — не одно и то же (второй метод автоматически добавляет перевод строки в конце).
VD>>>На этот раз подвиг работников Microsoft:
K>>Я с просони — откуда этот код?
S>MSDN как я понял S>Может я тоже спросони
это код из Visual Studio SDK
("C:\Program Files\Visual Studio 2005 SDK\2006.12\VisualStudioIntegration\Common\Source\CSharp\Project\idebuildlogger.cs")
Здравствуйте, PhantomIvan, Вы писали:
VD>>>>На этот раз подвиг работников Microsoft:
K>>>Я с просони — откуда этот код?
S>>MSDN как я понял S>>Может я тоже спросони
PI>это код из Visual Studio SDK PI>("C:\Program Files\Visual Studio 2005 SDK\2006.12\VisualStudioIntegration\Common\Source\CSharp\Project\idebuildlogger.cs")
так по названию файла видно)
человек, судя по всему, не знал, как определено сложение с null-строкой (а это действительно не очевидно), и вместо экспериментов/поисков за 15 секунд написал безопасный код, работающий для любого случая.
Здравствуйте, IvanDunaev, Вы писали:
ID>человек, судя по всему, не знал, как определено сложение с null-строкой (а это действительно не очевидно), и вместо экспериментов/поисков за 15 секунд написал безопасный код, работающий для любого случая.
Ага. Человек еще незнал, что полным маразмом является использовать StringBuilder для конкатинации двух строк. Зато человек знал инструкцию по которой для генерации строкнадо использовать StringBuilder. Головой своей человек явно пользоваться не приучен (с рождения), по-этому он взял и тупо выполнил инструкцию.
Если проблема была бы только с null, то он мог бы хотя бы не использовать StringBuilder.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lepsik, Вы писали:
L>Я думаю ты просто не понимаешь как работает эта функция, к тому же в ряде случаев оригинал работает гораздо быстрее твоего кода
Приятно встретить настоящего эксперта по дотнету! Поделись опытом с начинающим, расскажи в каких именно случаях "оригинал работает гораздо быстрее"?
Ну, и про то что я не понимаю тоже очень любопытно. (надо же опыта набираться)
А то может я зря идусятника обидел? Вот конфиз то будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Я думаю ты просто не понимаешь как работает эта функция, к тому же в ряде случаев оригинал работает гораздо быстрее твоего кода
VD>Приятно встретить настоящего эксперта по дотнету! Поделись опытом с начинающим, расскажи в каких именно случаях "оригинал работает гораздо быстрее"?
В дебаге при пустой и при null строках:
FormatMessage1( <null> ) : 265ms
FormatMessage2( <null> ) : 281ms
Замечу, именно в дебаге, в релизе второй вариант быстрее.
Только не надо кидать в меня палками, я просто замерял время и подкинул повод для размышления.
Здравствуйте, Demon, Вы писали:
D>Замечу, именно в дебаге, в релизе второй вариант быстрее.
Предлагаешь развить тему в сторону юмористического тестировани?
Тогда приводи исходники тестов. Но предварительно, на всякий пожарный, очень советую прочесть раздел "Тесты" из статьи Как не надо писать статьи
Здравствуйте, VladD2, Вы писали:
D>>Замечу, именно в дебаге, в релизе второй вариант быстрее.
VD>Предлагаешь развить тему в сторону юмористического тестировани?
Плохо понимаю, что такое "юмористическое тестирование", но почему бы не потрепаться.
Заранее предупрежу, если кто не понял, я не намерян отстаивать ни одно из предложенных решений. Просто Lepsik сказал "в ряде случаев оригинал работает гораздо быстрее твоего кода", и мне стало интересно.
VD>Тогда приводи исходники тестов. Но предварительно, на всякий пожарный, очень советую прочесть раздел "Тесты" из статьи Как не надо писать статьи
Вот. Функции FormatMessage1 и FormatMessage2 точь в точь изначальные.
int amount = 10 * 1000 * 1000;
string[] ss = new string[] { null, "", "qwre" };
foreach ( string s in ss )
{
int t1 = System.Environment.TickCount;
for ( int i = 0; i < amount; i++ )
{
FormatMessage1( s );
}
int dt1 = System.Environment.TickCount - t1;
System.Console.WriteLine( "FormatMessage1( {0} ) : {1}ms",
s == null ? "<null>" : ("\"" + s + "\""), dt1 );
int t2 = System.Environment.TickCount;
for ( int i = 0; i < amount; i++ )
{
FormatMessage2( s );
}
int dt2 = System.Environment.TickCount - t2;
System.Console.WriteLine( "FormatMessage2( {0} ) : {1}ms",
s == null ? "<null>" : ("\"" + s + "\""), dt2 );
System.Console.WriteLine();
}
(в сторону): Сейчас начнутся указания, типа "а надо было перегружаться между тестами", "надо было GC запускать".
Кстати, в статье, первые два абзаца раздела "Тесты" какие-то бредовые.
"... если вы тестируете скорость ... проверку результатов лучше выполнять ...". Зачем связали тестирование на корректность и на скорость?
Здравствуйте, Lepsik, Вы писали:
L> к тому же в ряде случаев оригинал работает гораздо быстрее твоего кода
Интересно, как часто вызывается данная функция? Будет ли программа, вызывающая её, работать гораздо быстрее в целом, если мы выиграем пару тактов процессора?