Здравствуйте, Vi2, Вы писали:

IS>>А что это по твоему, как не оптимизиция ?
Vi2>Это "пища" для оптимизирующего компилятора. Иначе же зачем он нужен?!

Ты хочешь сказать, что MSFT у себя на уме и их бест практисес имеют вполне прикладной смысл?

То есть когда DEV пишет код с использованием StringBuilder-a, он не только явно показывает другим
DEV что этот код оптимален потому что он сбацан из набора Best Practices, поднимая в общем-то общую
культуру кодирования в компании, но и подсказывает компилятору в каком именно месте провести агрессивную
оптимизацию? Хитро.

Здравствуйте, VladD2, Вы писали:

VD>Ага. Человек еще незнал, что полным маразмом является использовать StringBuilder для конкатинации двух строк.

а для чего использовать StringBuilder как не для конкатенации?

VD>Зато человек знал инструкцию по которой для генерации строкнадо использовать StringBuilder. Головой своей человек явно пользоваться не приучен (с рождения), по-этому он взял и тупо выполнил инструкцию.

в командной разработке это и к лучшему.

в целом напоминает претензии кустаря, делающего резные расписные табуретки, к стулу, сделанном на станке.

Здравствуйте, IvanDunaev, Вы писали:

ID>Здравствуйте, VladD2, Вы писали:

VD>>Ага. Человек еще незнал, что полным маразмом является использовать StringBuilder для конкатинации двух строк.

ID>а для чего использовать StringBuilder как не для конкатенации?

Ну для конкатенации двух строк вполне достаточно:

return string1 + string2;

А StringBuilder подойдёт для чего нибудь более сложного:

StringBuilder s = new StringBuilder(list.Lenght * 50 + 50);
foreach (Item item in list) {
    s.AppendFormat("...{0}...", item.ToString()/* размер примерно равен 40-50 */);
}
s.Append("Добавим ещё чего нить");
return s.ToString();

Здравствуйте, master_of_shadows, Вы писали:

__>Ну для конкатенации двух строк вполне достаточно:

__>

__>return string1 + string2;
__>

__>А StringBuilder подойдёт для чего нибудь более сложного:

__>

__>StringBuilder s = new StringBuilder(list.Lenght * 50 + 50);
__>foreach (Item item in list) {
__>    s.AppendFormat("...{0}...", item.ToString()/* размер примерно равен 40-50 */);
__>}
__>s.Append("Добавим ещё чего нить");
__>return s.ToString();
__>

ваау, кто бы мог подумать. вы всерьез думаете, что это может быть для кого-то откровением?

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

Здравствуйте, konsoletyper, Вы писали:

K>Интересно, как часто вызывается данная функция? Будет ли программа, вызывающая её, работать гораздо быстрее в целом, если мы выиграем пару тактов процессора?

По меркам компьютера — раз в 10 лет. Она вызывается при выводе сообщений об ошибках в окно Output. Так что рассуждать о производительности тут просто смешно. Но дело ведь не в этом. Лично мне интересен полет фантазии товарища написавшего подобное.

Здравствуйте, IvanDunaev, Вы писали:

ID>а для чего использовать StringBuilder как не для конкатенации?

Для генерации строк из заранее неизвестного количества подстрок или значений (преобразумых в строки).
Если стоит задача сложить Х строк, то стринг-билдер тут оверкил. Это грамоздко и бессмысленно. Конечно в большинстве случаев разницу будет в микроскоп не увидить, но дело даже не в скорости.

VD>>Зато человек знал инструкцию по которой для генерации строкнадо использовать StringBuilder. Головой своей человек явно пользоваться не приучен (с рождения), по-этому он взял и тупо выполнил инструкцию.

ID>в командной разработке это и к лучшему.

Да, да. Не думать головой в командной разработке — это очень важно. Только я лучше буду держаться по дальше от таких команд и продуктов их выпускающих.

ID>в целом напоминает претензии кустаря, делающего резные расписные табуретки, к стулу, сделанном на станке.

Нда. Во истину индус — это не национальность. Это образ мышления.

Здравствуйте, Demon, Вы писали:

D>(в сторону): Сейчас начнутся указания, типа "а надо было перегружаться между тестами", "надо было GC запускать".

Зачем? Я бы просто посоветовал "включить" голову и подумать над тем, что ты измерял.

Первые два варианта не приводят к использованию StringGuilder-а, так как срабатывает проверка:

if (string.IsNullOrEmpty(message))
    return Environment.NewLine;

в приложении она практически бесполезна, так как сообщения с пустым телом — это нонсенс и кроме как в случае ошибки возникнуть не могут.

Ну, да добавь эти строки во второй варинат и разница мужду ними исчезнет. А обуславливается разница тем, что string.Concat() делает чуть больше проверок и перенаправляет вызов более универсальной функции. Реально этот "оврехэд" настолько мал (худший вариант практически на порядок меньше реальной конкатинации), что учитывать его — это маразм.

Ну, а третий варинат (где конкатинируется маленькая, но реальная строка "qwre") как раз замечательно демонстрирует, что использовать StringGuilder для конкатинации двух строк — это оверкил.

Конечно тестирование в дебаге — это бессмысленное занятие, но даже в нем StringGuilder в двое медленее. Оно и понятно, ведь кроме собственно конкатинации строк там создается еще лишний объект и делаются лишние проверки.

D>Кстати, в статье, первые два абзаца раздела "Тесты" какие-то бредовые.
D>"... если вы тестируете скорость ... проверку результатов лучше выполнять ...". Зачем связали тестирование на корректность и на скорость?

Ужас какой. Неужели ты не понимаешь таких банальных вещей? При некооректных результатах все измерения будут так же некорректными. Нда, блин. Эту тему нужно не в юмор было кидать, так как это уже совсем грустно.

Здравствуйте, VladD2, Вы писали:

K>>Интересно, как часто вызывается данная функция? Будет ли программа, вызывающая её, работать гораздо быстрее в целом, если мы выиграем пару тактов процессора?

VD>По меркам компьютера — раз в 10 лет. Она вызывается при выводе сообщений об ошибках в окно Output. Так что рассуждать о производительности тут просто смешно. Но дело ведь не в этом. Лично мне интересен полет фантазии товарища написавшего подобное.

Просто меня удивило, что товарищ Lepsik придрался к производительности, как и вообще удивляют многие другие товарищи, которые оптимизируют всё, что не лень. ИМХО, в таких случаях важна читабельность кода, а не производительность. А если иметь прямые руки, светлый ум, и, главное, правильный компилятор правильного языка , то можно сочетать производительность с читабельностью.

Здравствуйте, konsoletyper, Вы писали:

K>Просто меня удивило, что товарищ Lepsik придрался к производительности, как и вообще удивляют многие другие товарищи, которые оптимизируют всё, что не лень. ИМХО, в таких случаях важна читабельность кода, а не производительность.

Ага. Я по началу даже было огарчился, что вообще про производительность ляпнул. Конкрено в этм месте о ней и говорить то глупо. Но потом я понял, что пожалуй — это была оговорка по фрэйду. Тут же нашлись местные индусы которые не приминули продемонстрировать образ мышеления который нужно иметь, чтобы рождать на свет подобных жутиков. Ведь одно дело увидить индусяцкий код, а другое услышать обоснование того как такое можно было написать.

K>А если иметь прямые руки, светлый ум, и, главное, правильный компилятор правильного языка , то можно сочетать производительность с читабельностью.

Это да. Но боюсь, что те кто серьезно расуждоает о производительности и темболее оправданности такого кода до правильного компилятора правильного языка не доросли. Ну, да оно и к лучшему. Так что не будем говорить как он называется.

Здравствуйте, IvanDunaev, Вы писали:

ID>речь идет о "засушивании" кода, когда единообразие и формальность подхода превалируют над частностями, позволяющими выиграть пару строк / тактов. конечно, данный конктретный случай слишком гиперболистичен, чтобы служить типичным примером.

Тебе такие слова как "читаемость кода" что-то говорят? Или ради единообразия ты готов всю жизнь смотреть на ровныи и стройные ряды макароного кода?

Здравствуйте, VladD2, Вы писали:

D>>(в сторону): Сейчас начнутся указания, типа "а надо было перегружаться между тестами", "надо было GC запускать".
VD>Зачем? Я бы просто посоветовал "включить" голову и подумать над тем, что ты измерял.
Я измерял скорость выполнения двух функций на разных входных данных.

VD>Первые два варианта не приводят к использованию StringGuilder-а, так как срабатывает проверка:
VD>

VD>if (string.IsNullOrEmpty(message))
VD>    return Environment.NewLine;
VD>

VD>в приложении она практически бесполезна, так как сообщения с пустым телом — это нонсенс и кроме как в случае ошибки возникнуть не могут.
Так изначально и говорилось "в ряде случаев оригинал работает гораздо быстрее твоего кода". То, что эти случаи возникают крайне редко, не означает, что скорость их выполнение мерять нельзя. А если в этих случаях функция будет выполняться несколько часов (преувеличиваю, конечно)? Кстати, если смотреть только на эту функцию, не принимаю во внимание для чего она используется, вероятность появления какого-либо значения в параметре предсказать нельзя. Т.ч. если человеку задано написать функцию и померять скорость ее выполнения, замеры должны покрывать все множество входных значений (ну это по хорошему).

VD>Ну, да добавь эти строки во второй варинат и разница мужду ними исчезнет. А обуславливается разница тем, что string.Concat() делает чуть больше проверок и перенаправляет вызов более универсальной функции. Реально этот "оврехэд" настолько мал (худший вариант практически на порядок меньше реальной конкатинации), что учитывать его — это маразм.
Зато на других входных данных вторая функция замедлится. Такими шагами ты докатишься до первого варианта.

VD>Конечно тестирование в дебаге — это бессмысленное занятие, но даже в нем StringGuilder в двое медленее. Оно и понятно, ведь кроме собственно конкатинации строк там создается еще лишний объект и делаются лишние проверки.
Согласен. Я потому и указал изначально, что первый быстрее только в дебаге. Если кто-то расценил это как довод в пользу использования первого варианта — это его проблемы.

D>>Кстати, в статье, первые два абзаца раздела "Тесты" какие-то бредовые.
D>>"... если вы тестируете скорость ... проверку результатов лучше выполнять ...". Зачем связали тестирование на корректность и на скорость?

VD>Ужас какой. Неужели ты не понимаешь таких банальных вещей? При некооректных результатах все измерения будут так же некорректными. Нда, блин. Эту тему нужно не в юмор было кидать, так как это уже совсем грустно.

Так, если ты не понял то, что я сказал, это не означает, что я дурак. Хотя, наверное, дурак, раз не смог толком объяснить.
Повторюсь "Зачем связали тестирование на корректность и на скорость?". Тесты нужно писать как можно более мелкие. Т.е. что бы они тестировали как можно меньшую функциональность. В этом случае, когда из пачки тестов один отвалится, проблемное место будет более локализованное.
В данном случае я бы написал в стиле "прежде чем тестировать скорострельность, проверьте корректность". Хотя можно в любом порядке, но тогда рассматривать их как транзакцию: если хоть один тест не прошел, значит и другие могли наврать.

Здравствуйте, VladD2, Вы писали:

VD>Для генерации строк из заранее неизвестного количества подстрок или значений (преобразумых в строки).
VD>Если стоит задача сложить Х строк, то стринг-билдер тут оверкил. Это грамоздко и бессмысленно. Конечно в большинстве случаев разницу будет в микроскоп не увидить, но дело даже не в скорости.

Вчера перешерстил Reflector`ом код из сборки system. Мама дорогая, там все на стрингбилдере!!!
Вот например, Path.IO

public static string GetTempFileName()
{
      string a_TmpPath = Path.GetTempPath();
      new FileIOPermission(FileIOPermissionAccess.Write, a_TmpPath).Demand();
      StringBuilder sb = new StringBuilder(MAX_PATH);
      if (Win32Native.GetTempFileName(a_TmpPath, "tmp", 0, sb) == 0)
      {
            __Error.WinIOError();
      }
      return sb.ToString();
}

Здравствуйте, VladD2, Вы писали:

VD>Тебе такие слова как "читаемость кода" что-то говорят?

а ты можешь дать формальное определение читаемости, без традиционных фобических девиаций?

VD>Или ради единообразия ты готов всю жизнь смотреть на ровныи и стройные ряды макароного кода?

я готов спокойно воспринимать пусть неидеальный, но достаточно добротный и лишенный серьезных изъянов код, потому что я реалист и мне некогда атаковать ветряные мельницы.

Здравствуйте, IvanDunaev, Вы писали:

ID>ваау, кто бы мог подумать. вы всерьез думаете, что это может быть для кого-то откровением?
Удивительный человек, задал вопрос, получил ответ и начал возмущаться. Кстати да, думаю данный код будет откровением для автора изначального кода.

ID>речь идет о "засушивании" кода, когда единообразие и формальность подхода превалируют над частностями, позволяющими выиграть пару строк / тактов. конечно, данный конктретный случай слишком гиперболистичен, чтобы служить типичным примером.
Здесь что то не понял .

Здравствуйте, IvanDunaev, Вы писали:

ID>Здравствуйте, VladD2, Вы писали:

VD>>Тебе такие слова как "читаемость кода" что-то говорят?

ID>а ты можешь дать формальное определение читаемости, без традиционных фобических девиаций?

Формальное определение слвам вообще дать нельзя. Нет формального механизма. А просто определение дать могу за проста:
Readability
Удобочитаемость

VD>>Или ради единообразия ты готов всю жизнь смотреть на ровныи и стройные ряды макароного кода?

ID>я готов спокойно воспринимать пусть неидеальный, но достаточно добротный и лишенный серьезных изъянов код, потому что я реалист и мне некогда атаковать ветряные мельницы.

Макаронный код никогда не будет добротным. Он является причиной других проблем. Люди которые не пользуются принципом выбора наиболее простых решений (из имеющихся в наличии и удовлетворяющих прочим условиям) в принципе не способны на решение сложных задач.

Здравствуйте, serg_fork, Вы писали:

_>Вчера перешерстил Reflector`ом код из сборки system. Мама дорогая, там все на стрингбилдере!!!
_>Вот например, Path.IO
_>

_>public static string GetTempFileName()
_>{
_>      string a_TmpPath = Path.GetTempPath();
_>      new FileIOPermission(FileIOPermissionAccess.Write, a_TmpPath).Demand();
_>      StringBuilder sb = new StringBuilder(MAX_PATH);
_>      if (Win32Native.GetTempFileName(a_TmpPath, "tmp", 0, sb) == 0)
_>      {
_>            __Error.WinIOError();
_>      }
_>      return sb.ToString();
_>}
_>

На самом деле этот код как раз оправдан. Дело в том, что в данном случае программист выполнял требования PInvoke. Фнукция GetTempFileName это не управляемая функция импортируемая из kernel32.dll.

Таковы уже особенности интеропа с неуправляемым кодом. Ему нужно было передать буфер заведомо приемлемого размера и потом только часть этого буфера интерпретировать как строку. В нитеропе дотнета для этих целей шататно используется StringBuilder.

Здравствуйте, Demon, Вы писали:

D>Так изначально и говорилось "в ряде случаев оригинал работает гораздо быстрее твоего кода".

И где ты усмотрел "гораздо быстрее"? Или 10 милисек. на 10 миллионов итераций это в некоторых кругах и считается горазно быстрее? Ты вообще понимашь, что в случае пусой строки и темболее null-а речь уже идет о тактах процессора? Это вообще осбуждать бессмысленно.

Я не даром тебе дал ссылку на ту статью. Там есть очено правильные слова и по этому поводу:

Масштаб
Если вы решили что-либо превознести, или наоборот, счесть существенным недостатком, подумайте, насколько это повлияет на конечный результат. Часто бывает так, что автор, зацепившись за, в целом, неважную вещь, делает из мухи слона, либо представляя ее как панацею, либо, наоборот, устраивая над ней великое судилище. Между тем, факт может не стоить выеденного яйца на фоне других достоинств и недостатков описываемой технологии, языка или платформы.

D>То, что эти случаи возникают крайне редко, не означает, что скорость их выполнение мерять нельзя.

Еще раз. Там вообще говорить не очем когда речь идет о пустх строках. Есть такое понятие как осмысленная точность измерений.

D> А если в этих случаях функция будет выполняться несколько часов (преувеличиваю, конечно)?

Конечно приувеличивашь. Смысла в выполнении пустого цикла с одним if-ом нет. Темболее его нет смысла выполнять несколько часов. А появление первого осмысленного действия приведет к тому, что результат проверок на null исчезнет.

D> Кстати, если смотреть только на эту функцию, не принимаю во внимание для чего она используется, вероятность появления какого-либо значения в параметре предсказать нельзя.

Ага. Я это называю "сфероконемания". Функция с названием FormatMessage() пребавляющая конец строки к другой строке может не говорить о ее применении только тому кто совсем оторвался от реальности.

D> Т.ч. если человеку задано написать функцию и померять скорость ее выполнения, замеры должны покрывать все множество входных значений (ну это по хорошему).

Уломал речистый. Тогда все же порудись объяснить зачем ее автор использовал StringBuilder. Ведь твои смелые научные эксперементы хорошо показали бессысленность этого занятия. Не так ли?

VD>>Конечно тестирование в дебаге — это бессмысленное занятие, но даже в нем StringGuilder в двое медленее. Оно и понятно, ведь кроме собственно конкатинации строк там создается еще лишний объект и делаются лишние проверки.
D>Согласен. Я потому и указал изначально, что первый быстрее только в дебаге. Если кто-то расценил это как довод в пользу использования первого варианта — это его проблемы.

А зачем ты это указал, если StringGuilder медленее всегда? И вообще к чему это обсуждение? Ты серьезно считашь код приведенного метода разумным?

D>Повторюсь "Зачем связали тестирование на корректность и на скорость?".

Отвечаю. Никто ничего не связывал. Ты умудрился прочесть книгу и увидить сам знаешь что. Прочти еще раз, внимательно.

Здравствуйте, VladD2, Вы писали:

D>>Так изначально и говорилось "в ряде случаев оригинал работает гораздо быстрее твоего кода".

VD>И где ты усмотрел "гораздо быстрее"? Или 10 милисек. на 10 миллионов итераций это в некоторых кругах и считается горазно быстрее? Ты вообще понимашь, что в случае пусой строки и темболее null-а речь уже идет о тактах процессора? Это вообще осбуждать бессмысленно.
А я ничего не усматривал. Я просто померял скорость. И моей целью не было доказать вышерасположенное утверждение. Вот, например, ты наверняка считал, что твоя функция всегда работает быстрее, ан нет. Ну если не ты, то кто-то другой наверняка. Вот тебе (ему) повод подумать, а почему в этих случаях она на копейки, но медленнее. А может можно написать функцию, работающую раза в два быстрее?

VD>Я не даром тебе дал ссылку на ту статью. Там есть очено правильные слова и по этому поводу:
VD>

Масштаб
VD>Если вы решили что-либо превознести, или наоборот, счесть существенным недостатком, подумайте, насколько это повлияет на конечный результат. Часто бывает так, что автор, зацепившись за, в целом, неважную вещь, делает из мухи слона, либо представляя ее как панацею, либо, наоборот, устраивая над ней великое судилище. Между тем, факт может не стоить выеденного яйца на фоне других достоинств и недостатков описываемой технологии, языка или платформы.

Совершенно согласен. Вот только к данной ситуации они не особо применимы. Я же ничего не "превозносил", и ничего не называл "существенным недостатком". Я всего то предложил подумать, почему результаты получились такие.

D>> А если в этих случаях функция будет выполняться несколько часов (преувеличиваю, конечно)?

VD>Конечно приувеличивашь. Смысла в выполнении пустого цикла с одним if-ом нет. Темболее его нет смысла выполнять несколько часов. А появление первого осмысленного действия приведет к тому, что результат проверок на null исчезнет.

А ты всегда по коду можешь сказать, сколько времени он будет выполняться?
А может в какой-нить реализации .Net код "message + Environment.NewLine" будет вылавливать null значения через эксепшены? А у тебя все эксепшены будут логироваться в файл.

D>> Кстати, если смотреть только на эту функцию, не принимая во внимание для чего она используется, вероятность появления какого-либо значения в параметре предсказать нельзя.

VD>Ага. Я это называю "сфероконемания". Функция с названием FormatMessage() пребавляющая конец строки к другой строке может не говорить о ее применении только тому кто совсем оторвался от реальности.

Ну раскажи мне, оторванному от реальности, в каком проценте вызовов этой функции ей передается пустая строка.

D>> Т.ч. если человеку задано написать функцию и померять скорость ее выполнения, замеры должны покрывать все множество входных значений (ну это по хорошему).

VD>Уломал речистый. Тогда все же порудись объяснить зачем ее автор использовал StringBuilder. Ведь твои смелые научные эксперементы хорошо показали бессысленность этого занятия. Не так ли?
Не так. Они показали, что он медленный в данном случае, но у него могут быть другие достоинства. А может и не быть. Не надо меня приписывать к агитаторам первого варианта.
Это уже другие делали, не хочется мне фантазировать на эту тему.

VD>>>Конечно тестирование в дебаге — это бессмысленное занятие, но даже в нем StringGuilder в двое медленее. Оно и понятно, ведь кроме собственно конкатинации строк там создается еще лишний объект и делаются лишние проверки.
D>>Согласен. Я потому и указал изначально, что первый быстрее только в дебаге. Если кто-то расценил это как довод в пользу использования первого варианта — это его проблемы.

VD>А зачем ты это указал, если StringGuilder медленее всегда?
Ты не путай теплое с мягким. Указание было для того, чтобы народ не ломанулся в эти двери. А StringBuilder здесь не причем.
VD>И вообще к чему это обсуждение? Ты серьезно считашь код приведенного метода разумным?
Отвечу сразу на два вопроса.
Я считаю неразумным делить мир на черное и белое. Да к тому же ставить себя на белую часть.
Если ты уверен, что нечто одно белее чем нечто другое, никогда не будет вредным присмотреться и понять в каком месте оно белее. Даже если белый медведь вцелом белее бурого, нос у него может быть чернее.


D>>Повторюсь "Зачем связали тестирование на корректность и на скорость?".

VD>Отвечаю. Никто ничего не связывал. Ты умудрился прочесть книгу и увидить сам знаешь что. Прочти еще раз, внимательно.
Прочитал. Не помогло. Перед сном еще поперечитываю.
Предлагаю закрыть эту тему, т.к.
1. Тогда мне ночью будут сниться сортирующие компиляторы
2. На лицо зашоренность взгляда. Как у тебя, так и у меня. Тяжело взглянуть на вещь со стороны, отличной от первоначальной.

Здравствуйте, Demon, Вы писали:

D>А я ничего не усматривал. Я просто померял скорость. И моей целью не было доказать вышерасположенное утверждение. Вот, например, ты наверняка считал, что твоя функция всегда работает быстрее, ан нет. Ну если не ты, то кто-то другой наверняка. Вот тебе (ему) повод подумать, а почему в этих случаях она на копейки, но медленнее. А может можно написать функцию, работающую раза в два быстрее?

Причём тут вообще скорость? Никто ничего кроме тебя вообще не думал. Заметь, это ты начал распространяться по поводу скорости.

D>Совершенно согласен. Вот только к данной ситуации они не особо применимы. Я же ничего не "превозносил", и ничего не называл "существенным недостатком". Я всего то предложил подумать, почему результаты получились такие.

Вот и будем думать, когда такая функция будет вызываться по 1000000 раз в сенкунду. А сейчас то зачем голову ломать? Главное — читабельность. А так мы и читабельность гробим, и время своё на обдумывание такой мелочи.

D>А может в какой-нить реализации .Net код "message + Environment.NewLine" будет вылавливать null значения через эксепшены? А у тебя все эксепшены будут логироваться в файл.

Не будет. Или это будет уже не реализацией .NET (т.к. все эти вещи в стандарте оговорены), так что спросу тут никакого быть не может.

D>Не так. Они показали, что он медленный в данном случае, но у него могут быть другие достоинства. А может и не быть. Не надо меня приписывать к агитаторам первого варианта.
D>Это уже другие делали, не хочется мне фантазировать на эту тему.

Ну, пошли размышления по поводу того, какие достоинства есть у StringBuilder'а. Может, отдельную ветку по этому поводу откроем? Или к администрации RSDN постучимся и создадим форум, посвящённый этой тематике, а тебя модератором назначим?

D>Я считаю неразумным делить мир на черное и белое. Да к тому же ставить себя на белую часть.
D>Если ты уверен, что нечто одно белее чем нечто другое, никогда не будет вредным присмотреться и понять в каком месте оно белее. Даже если белый медведь вцелом белее бурого, нос у него может быть чернее.

Да вы, батенька, философ! А со стороны это выглядит так. Ты поделил мир на чёрное и белое согласно только что приведённому критерию, причём всех, кто по твоему скромному мнению этих правил не придерживается, тот находится на чёрной стороне, а ты (кто бы сомневался) — на белой.

Здравствуйте, konsoletyper, Вы писали:

D>>А я ничего не усматривал. Я просто померял скорость. И моей целью не было доказать вышерасположенное утверждение. Вот, например, ты наверняка считал, что твоя функция всегда работает быстрее, ан нет. Ну если не ты, то кто-то другой наверняка. Вот тебе (ему) повод подумать, а почему в этих случаях она на копейки, но медленнее. А может можно написать функцию, работающую раза в два быстрее?

K>Причём тут вообще скорость?
При том, что в этом поддереве обсуждения, идет разговор про скорость.
K>Никто ничего кроме тебя вообще не думал.
Зачем же ты всех так оговариваешь? Может быть ты ни о чем не думал.
K>Заметь, это ты начал распространяться по поводу скорости.
Заметь, не я. В корневом посте было "Причем получится не только читабельнее, но и чуточку быстрее".

D>>Совершенно согласен. Вот только к данной ситуации они не особо применимы. Я же ничего не "превозносил", и ничего не называл "существенным недостатком". Я всего то предложил подумать, почему результаты получились такие.

K>Вот и будем думать, когда такая функция будет вызываться по 1000000 раз в сенкунду. А сейчас то зачем голову ломать? Главное — читабельность. А так мы и читабельность гробим, и время своё на обдумывание такой мелочи.
Иногда стоит подумать не только над насущными проблемами.

D>>А может в какой-нить реализации .Net код "message + Environment.NewLine" будет вылавливать null значения через эксепшены? А у тебя все эксепшены будут логироваться в файл.

K>Не будет. Или это будет уже не реализацией .NET (т.к. все эти вещи в стандарте оговорены), так что спросу тут никакого быть не может.
Точно? Ссылочку плиз, а то меня как-то сомненья гложут.
Но даже если и невозможен такой вариант, можно придумать нечто аналогичное.

D>>Не так. Они показали, что он медленный в данном случае, но у него могут быть другие достоинства. А может и не быть. Не надо меня приписывать к агитаторам первого варианта.
D>>Это уже другие делали, не хочется мне фантазировать на эту тему.

K>Ну, пошли размышления по поводу того, какие достоинства есть у StringBuilder'а. Может, отдельную ветку по этому поводу откроем? Или к администрации RSDN постучимся и создадим форум, посвящённый этой тематике, а тебя модератором назначим?
Где пошли? Куда пошли? По-моему, я довольно четко сказал, что не хочу обсуждать StringBuilder.

D>>Я считаю неразумным делить мир на черное и белое. Да к тому же ставить себя на белую часть.
D>>Если ты уверен, что нечто одно белее чем нечто другое, никогда не будет вредным присмотреться и понять в каком месте оно белее. Даже если белый медведь вцелом белее бурого, нос у него может быть чернее.

K>Да вы, батенька, философ! А со стороны это выглядит так. Ты поделил мир на чёрное и белое согласно только что приведённому критерию, причём всех, кто по твоему скромному мнению этих правил не придерживается, тот находится на чёрной стороне, а ты (кто бы сомневался) — на белой.
Ээээ, какому критерию? каких правил? Я высказал свою точку зрения, и естественно, она мне кажется "белее". Это ж философия, тут ничего не докажешь