На мой взгляд, дискуссия, начатая здесь

http://www.rsdn.ru/Forum/Message.aspx?mid=1457243&only=1

Автор: VladD2
Дата: 27.10.05

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

Обсуждать то, что делал VladD2 в своей ранней разработке — не буду. В молодости и не такие ошибки делаешь, мог бы и о своих порассказать...

Но вот результаты — обсудить стоит.

Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?

Эксперименты, проведенные мной и другими , показали — чтение по одному байту замедляет работу в десятки раз. Сейчас, на Windows XP. Что там было во времена MS-DOS — обсуждать я не буду.

Следует ли из этого, что читать побайтно вообще нельзя ? Ни в коем случае!
Истина, как всегда, конкретна. Если предстоит читать из файла (а то и из консольного ввода) два десятка байтов несколько раз за жизненный цикл программы — да здесь хоть по байту читайте, хоть по полбайта . Потому что не скажется это никак ни на чем. И тот, кто здесь начнет оптимизировать, только время зря потратит.

Стоит ли все же это оптимизировать ? Во многих случаях — да. Истина, опять же конкретна. Если речь идет о чтении файлов размерами в Мб, и делается это многократно — обязательно. Потому что иначе вы просто получите ничем не оправданную потерю производительности. Бессмысленную потерю. И не надо мне говорить, что, дескать, потом профайлером обнаружим и исправим. Понять это и на стадии проектирования можно, если правильно задачу оценить. И переделывать здесь совсем незачем — надо просто сразу как следует сделать

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

Вот этот вопрос самый интересный. Скажется в данном случае или нет ? Вообще-то если логика задачи рассматривает входной поток как структуру "последовательность" — всякая попытка читать не побайтно есть нарушение этой абстракции, а, следовательно, и переход к некоторому ухудшению дизайна. Можно, конечно, скрыть это на определенном уровне, но все же некоторое нарушение идеи здесь есть. Не столь ясным дизайн будет, что ни говори, а это правда. И вот здесь мое мнение — это надо вытерпеть. Ради того, чтобы это потом нормально работало. Увы, не любое красивое и изящное решение является еще и практически применимым. Можно, конечно, при постройке дома рассуждать о пилястрах и колоннах, портиках и фасадах, но все же не мешало бы и о кирпичах и бетоне подумать. Иначе, простите, получив задание построить птицеферму, мы ей красивый фасад сделем в стиле барокко, только вот для кур там места не найдется

А чтобы такие ляпы не допускать — опыт нужен. И школа соответствующая. Проще говоря, надо еще во время учебы студентам объяснять, что делать надо как следует. Тогда они хоть понимать будут, что здесь почем. И стараться писать эффективно. Соответствующая культура у них будет. Вот этому я их и учу в меру своих способностей. А неэффективно писать они и без меня научатся

Выводы.

Я вовсе не призываю к оптимизации любой ценой. И те, кто меня в этом обвиняют — ломятся в открытую дверь.
Я призываю к неиспользованию заведомо неэффективных решений. Что, к сожалению, и будет иметь место, если программист элементарно не понимает, что здесь почем и относится к ресурсам как к бездонной бочке. А то, что это не так уж редко бывает — показывает исходный постинг. Если уж такой грамотный специалист, как VladD2 (говорю это без всякой иронии) допускает такие ляпы (и даже в этом я его не обвиняю, с кем не бывает), то что говорить о тех, кто только начинает!

В общем, я призываю думать. Думать, и искать наилучшее решение. И не сковывать себя при этом никакими шорами.

На пустом месте проблема .
Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

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

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

OT>по моему мнению такое графоманство на выводы тянет мало.



OT>а главное, что общий подход подменён частным случаем с многозначительными анализами результатов
OT>имхо оптимизация не сводится к посимвольному чтению и тп

А кто сказал, что сводится ? Что касается частного примера — так именно он тут и возник, увы.

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

M>На пустом месте проблема .
M> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

Естественно. Но я же не о нем

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

[offtopic]
Павел, коллега, вы похоже пытаетесь вывести некие универсальные законы которые должно воспринимать как некие откровения. Может быть мой опыт программирования и не столь велик и писать программы я стал в зрелом 32-х летнем возрасте, но если бы мне пришлось мучиться такими парадигмами, то уверен, что дальше задачи написания программы Hello_World.exe дело бы не сдвинулось. У меня нет опыта преподавания, потому мое мнение сугубо дилетанское — нет нужды загружать чужие мозги задачами которые не кричат, у всех своя голова, как и кто будет решать конкретную задачу зависить от обстоятельств и от человека.

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

Все верно. С тобой никто уже давно не спорит. Спор идет с вымышленным персонажем, который твердолобо считает а) эффективность единственным критерием качества софта и б) под эффективностью понимает только свое убогое восприятие стоимости операций.

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

- да они че, охренели списками пользоваться? Это же восемь байт на элемент оверхеду, и неминуемый сброс кэша процессора на каждое обращение по индексу! Надо блин массив использовать!

или

- какой дебил догадался воткнуть здесь массив? Это же перевыделение памяти на каждый Add! Связный список однозначно рулит

При этом никакого анализа частоты операций [] и Add этим персонажем не производится из принципа. А производится жосткая оптимизация, в которой и дважды связный список, и массив, заменяются на список массивов, указатели итемов утаптываются до 16 бит, а старшая часть хранится в самом списке. Код пестрит директивами asm, которые не дают компилятору сделать корректную оптимизацию этих чудо-действий.
Результат оказывается на 0.01% быстрее неоптимизированной версии. В остальном работает почти так же, кроме некоторых мелочей:
— попытка вызвать Remove на списке с элементом другого списка вызывает UB, а не exception
— запрос элемента с номером i больше Length возвращает элемент с номером i mod Length
— запрос элемента с любым номером у списка нулевой длины приводит к зацикливанию

Починка этих мелочей занимает три недели времени; после этого код становится на 15% медленнее неоптимизированной версии. Автора увольняют под благовидным предлогом.
Код становится доступным общественности благодаря истерике разработчика, который пришел на смену нашему персонажу и попытался понять, почему код по-прежнему тормозит и глючит — баги в логике поправить предшественник не успел.

Лично ты к этому персонажу никакого отношения не имеешь.

Но в природе и не такие чудеса встречаются. Приходят люди на собеседования и честно говорят: "Ну конечно список менее эффективен"...

Здравствуйте, OnThink, Вы писали:
OT>По слову "Оптимизация" можно найти несколько хороших книг и на русском языке
И большинство из них к алгоритмической оптимизации никакого отношения не имеют. Потому как для математика оптимизация — это нахождение экстремума некоторой функции

Кстати, встречал я однажды великолепную книгу издательства Мир. Точно название не вспомню, но что-то вроде "Сверхбыстрые алгоритмы". Там как раз рассказывалось про то, как что оптимизировать. Ну типа про алгоритм Кули-Тьюки для выполнения преобразования Фурье — убогий частный случай для N=2^K присутствует во всех библиотеках. Или там про то, как вычислить комплексное произведение быстрее, чем за два умножения и два сложения. Очень интересная книга.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:

S>Все верно. С тобой никто уже давно не спорит.

Спасибо хоть на этом.

>Спор идет с вымышленным персонажем, который твердолобо считает а) эффективность единственным критерием качества софта и б) под эффективностью понимает только свое убогое восприятие стоимости операций.

<skipped>

S>Лично ты к этому персонажу никакого отношения не имеешь.

Остается только одно понять — и зачем же вы все придумываете себе вымышленных персонажей и с ними упорно спорите ?

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

PD>Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?

It depends...
И профайлер действительно показывает.
И я действительно думаю, что сначала нужно сделать работающую программу, а только затем делать из нее быструю. И только в случае, если это будет экономически оправдано.

PD>Эксперименты, проведенные мной и другими , показали — чтение по одному байту замедляет работу в десятки раз. Сейчас, на Windows XP. Что там было во времена MS-DOS — обсуждать я не буду.


А это? Re[4]: История одной оптимизации

Автор: eao197
Дата: 28.10.05

На нормальных компиляторах и CRT нет замедления в десятки раз.

---

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

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

PD>Остается только одно понять — и зачем же вы все придумываете себе вымышленных персонажей и с ними упорно спорите ?

Наверное потому, что нормальных людей готовых поспорить совершенно не осталось Плюс, спорить с вымышленным персонажем намного выгоднее — все ответы этого персонажа тоже вымышлены (исходя из начальных условий) и достаточно часто просто абсурдны. Благодаря всему этому, очень легко показать себя споре с лучшей стороны (по сравнению с вымышленным собеседником) — подчеркнуть, что ты опытный специалист и твой опты не пару месяцев, а не меньше десяти лет (и этим никак не намекатся на то, что у собеседника опыт намного меньше — он же вымышленный), отмести возможные подозрения о тяжелом детсве и подорванной психике (что Вы доктор, никакого BASICа — я сразу на C писать начал). Ну и кроме всего прочего у виртуального персонажа нет личности следовательно, перейти на них в споре очень трудно... Главное только слишком сильно не поверить в этого вымышленного персонажа... А то, он еще и переспорить может. Вот, тогда, конфуз-то выйдет

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

PD>Остается только одно понять — и зачем же вы все придумываете себе вымышленных персонажей и с ними упорно спорите ?
Чтобы стало меньше реальных прототипов для этих персонажей

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

E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?

E>It depends...
E>И профайлер действительно показывает.
E>И я действительно думаю, что сначала нужно сделать работающую программу, а только затем делать из нее быструю. И только в случае, если это будет экономически оправдано.

Ну что же... каждый имеет на этот счет свое мнение.

E>А это? Re[4]: История одной оптимизации

Автор: eao197
Дата: 28.10.05

E>На нормальных компиляторах и CRT нет замедления в десятки раз.

С буферизацией stdio.h. Попробуй ReadFile. Я об этом писал.


E>Павел, имхо, пора закрывать эту тему. А то выглядит это все, как личные разборки.

Согласен.

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

E>>А это? Re[4]: История одной оптимизации

Автор: eao197
Дата: 28.10.05

E>>На нормальных компиляторах и CRT нет замедления в десятки раз.

PD>С буферизацией stdio.h. Попробуй ReadFile. Я об этом писал.

А нафига мне ReadFile? Это не портабельно.

PD>>>Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?

E>>It depends...
E>>И профайлер действительно показывает.
E>>И я действительно думаю, что сначала нужно сделать работающую программу, а только затем делать из нее быструю. И только в случае, если это будет экономически оправдано.

PD>Ну что же... каждый имеет на этот счет свое мнение.

Ага. Скажите об этом заказчику.
Я бы увольнял таких оптимизаторов (и не я один).
Когда в нормальной программе критичными по скорости являются только 4-5% (много RTFM), при оптимизации всей программы, мы ничего кроме нечитаемого кода не получаем. И это при оплате времени, потраченного на этот мазохизм. При том, что многие оптимизации железозависисмы и даже для тех 4% мы не всегда будем иметь прирост производительности.
А где Вас искать потом, когда программу скомпилируем допустим под новый фреймворк, и ваш оптимальный алгоритм пойдёт поперёк оптимизитора компиллятора? Куда высылать мешок п..лей?

З.Ы.
Это всё не касается оптимизации логики, которую называют "прямыми руками", и оптимизацией можно не считать.

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

E>А нафига мне ReadFile? Это не портабельно.

Так ведь начиналось с системных вызовов. А это здесь он и есть, через NtCreateFile

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


OT>Когда в нормальной программе критичными по скорости являются только 4-5% (много RTFM), при оптимизации всей программы, мы ничего кроме нечитаемого кода не получаем.

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

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

S>Здравствуйте, OnThink, Вы писали:
OT>>По слову "Оптимизация" можно найти несколько хороших книг и на русском языке
S>И большинство из них к алгоритмической оптимизации никакого отношения не имеют. Потому как для математика оптимизация — это нахождение экстремума некоторой функции

А для программиста это то же самое.
Только функция очень сложная

PD>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?

прочитайте строки на которые был ответ.

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

PD>Ну что же... каждый имеет на этот счет свое мнение.

Действительно очень трудно с токующим тетеревом общаться.

OT>>Когда в нормальной программе критичными по скорости являются только 4-5% (много RTFM), при оптимизации всей программы, мы ничего кроме нечитаемого кода не получаем.

PD>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?

Интересно посмотреть, как можно априорно выделить эти 4-5%.

S>>И большинство из них к алгоритмической оптимизации никакого отношения не имеют. Потому как для математика оптимизация — это нахождение экстремума некоторой функции

B>А для программиста это то же самое.
B>Только функция очень сложная

Не думаю, что функциональный подход здесь уместен.

Здравствуйте, Pavel Dvorkin,

Коллега, а вам не кажется, что вы делаете в точности то же самое, спорите с абсолютно не существующим противником?

Кто он, ваш оппонент? Где вы видели того, кто сказал бы, "нужно использовать медленные алгоритмы и писать неэффективные программы"?

Вам все хором поют о том, что на глаз определить узкое место как правило все равно не удается и о том, что скорость работы программы — это не самая важная ее особенность. И все. А что быстрые программы лучше медленных — вроде никто и не спорит.


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

Иными словами — а был ли мальчик? А может, мальчика-то никакого и не было?

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

PD>>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?

OT>прочитайте строки на которые был ответ.

Прочитайте строки, на которое было замечание. Ваши строки

>при оптимизации всей программы, мы ничего кроме нечитаемого кода не получаем.

Вот я и ответил, что ни о какой оптимизации всей программы речи не идет.

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

PD>>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?

OT>Интересно посмотреть, как можно априорно выделить эти 4-5%.

Тут ничего сложного нет. Берем Доркина:

PD>Я вовсе не призываю к оптимизации любой ценой. И те, кто меня в этом обвиняют — ломятся в открытую дверь.
PD>Я призываю к неиспользованию заведомо неэффективных решений. Что, к сожалению, и будет иметь место, если программист элементарно не понимает, что здесь почем и относится к ресурсам как к бездонной бочке. А то, что это не так уж редко бывает — показывает исходный постинг. Если уж такой грамотный специалист, как VladD2 (говорю это без всякой иронии) допускает такие ляпы (и даже в этом я его не обвиняю, с кем не бывает), то что говорить о тех, кто только начинает!

PD>В общем, я призываю думать. Думать, и искать наилучшее решение. И не сковывать себя при этом никакими шорами.

Последний абзац в данном случае придется выкинуть Но, ничего, действуем по следующей схеме:

1. Составляем чеклист оптимизаций.
2. Строго следуем чек листу при написании кода. Здесь главное проверять этот чеклист сразу. например, написал метод — проверил.

Что включить в чеклист?

1. (сразу возьмем ввод вывод) Увидел посимвольное чтение — пошел проверил что, ввод вывод буферизирован — что это и зачем нужно в данном случае не важно надо просто проверить и, исправить.

2. Копирование массивов. Если один массив копируется в другой то, тот при создании другого лучше сразу выделить память нужного объема. Почему именно — тоже не важно — это как тарелька...

Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение

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

TK>Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение
А не проще профайлером побаловаться?

С уважением, Gleb.

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

TK>>Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение
GZ>А не проще профайлером побаловаться?

Вот у тебя и получится, что опитимизировать будешь все приложение, а не 4-5% процентов. Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать. Если же институт понимания не дал, то сдача экзаменов научит заранее писать шпаргалки (они же чеклисты) и, возможно, правильно их использовать... Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе... Либо, надеяться на тех, кто в школе хорошо учился а потом, смартдрайв написал.

Вобщем, не слушайте Влада — еще не того насоветует (он тут рядом вообще кончину Win32 предрекал

GZ>>А не проще профайлером побаловаться?

TK>Вот у тебя и получится, что опитимизировать будешь все приложение, а не 4-5% процентов. Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать. Если же институт понимания не дал, то сдача экзаменов научит заранее писать шпаргалки (они же чеклисты) и, возможно, правильно их использовать... Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе... Либо, надеяться на тех, кто в школе хорошо учился а потом, смартдрайв написал.

Профайлером надо пользоваться, чтоб узкие места искать. Об этом была речь, я думаю. То, о чём ты пишешь здесь, по большому счёту не является оптимизацией. Оптимизация — это то, алгоритм чего ты привёл в прошлый раз. Оптимизация почти всегда ухудшает структуру кода и речь о том, чтобы применять её только в крайних специализированных случаях. А ухудшение читаемости кода вдоль всей его длины — это имхо великое зло.

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

TK>Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе...
Неее. Во первых профайлер не изменяет код. Он делает отчеты. Макаронный код — это пререгатива программиста. Ну а во-вторых, профайлер оперирует точными цифрами, а не догадками. В третьих — ты прав. Если писать лабуду вначале, то тебе никто не поможет. Знания сила. Надо выбирать оптимальные алгоритмы и оптимальные инструменты и стараться уместить в оптимальном дизайне. В четвертых — ты неправ. В любом случае ошибки производительности случаются независимо от нас. Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса. В пятых ты неправ потому что требования к оптимальному дизайну и оптимальным алгоритмам зачастую противоречивы. И вот что в этом противоречии выбрать и есть вопрос. Я выбираю оптимальный дизайн. Алгоритм я не знаю как поведет себя, могу заточить профайлером если понадобится и переделать на более сложный дизайн, а вот если плохой дизайн, то в случае чего будет полная сипука.

TK>(он тут рядом вообще кончину Win32 предрекал
Мечтатель. Оно еще всех нас переживет.

С уважением, Gleb.

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

M>На пустом месте проблема .
M> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

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

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

M>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

PD>Естественно. Но я же не о нем

А чем:

char ch = file.ReadChar();

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

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

TK>>Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе...
GZ>Неее. Во первых профайлер не изменяет код. Он делает отчеты. Макаронный код — это пререгатива программиста. Ну а во-вторых, профайлер оперирует точными цифрами, а не догадками.

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

GZ>В третьих — ты прав. Если писать лабуду вначале, то тебе никто не поможет. Знания сила. Надо выбирать оптимальные алгоритмы и оптимальные инструменты и стараться уместить в оптимальном дизайне. В четвертых — ты неправ. В любом случае ошибки производительности случаются независимо от нас.

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

GZ>Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса.

Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?

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

Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет... А вот переделка ошибок дизайна в "большом" приложении может стоить очень дорого. Это, хорошо, если это поймали на этапе тестирования. А если в эксплуатации? Сколько будет стоить исправление ошибки?

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

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

P>Павел, коллега, вы похоже пытаетесь вывести некие универсальные законы которые должно воспринимать как некие откровения. Может быть мой опыт программирования и не столь велик и писать программы я стал в зрелом 32-х летнем возрасте, но если бы мне пришлось мучиться такими парадигмами, то уверен, что дальше задачи написания программы Hello_World.exe дело бы не сдвинулось. У меня нет опыта преподавания, потому мое мнение сугубо дилетанское — нет нужды загружать чужие мозги задачами которые не кричат, у всех своя голова, как и кто будет решать конкретную задачу зависить от обстоятельств и от человека.

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

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

GZ>А не проще профайлером побаловаться?

Ты не понял, это типа такой тонкий стеб.

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

PD>Остается только одно понять — и зачем же вы все придумываете себе вымышленных персонажей и с ними упорно спорите ?

Слушай... Сделай, плиз, пример кода некоторого простого приложения. Ну, например, подсчитывающего количество слов некотором каталоге где находится море ХТМЛ-файлов.

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

Мама 10
Папа 100
я    3

В этом списке должны быть только слова удовлетворяющие понитию С++-идентефикатору (т.е. начинающиеся на букву или символв "_" и содержащие символы и цифры).

Потом ты объяснишь почему выбрал те или иные решения. Ну, а мы почитаем это описание и поймем что ты имеш в виду и под оптимизацией, и под оптимальностью.

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

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

PD>На мой взгляд, дискуссия, начатая здесь

PD>http://www.rsdn.ru/Forum/Message.aspx?mid=1457243&amp;only=1

Автор: VladD2
Дата: 27.10.05

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

Истин есть как минимум две. (С) Сергей Лукьяненко

PD>Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?

ИМХО, надо смотреть по ситуации.
Что делает программа? Это моделирование каких-то белков? Это новый 3D-шутер с фотографическими текстурами? Что-то, сделанное для Palm'a? Программа самонаведения зенитной ракеты? Ядро операциоонной системы? Какие-то вещи, где важна скорость или память? Тогда надо оптимизировать. Безусловно. Потому что в данном случае скорость работы — одно из первейших условий.
Вы собираетесь писать что-то для общего употребления? Бухгалтерию, броузер, какую-то фичу для ОС?
Сколько вы собираетесь разрабатывать программу? Месяц, полгода, год? Не случится ли так, что пока вы эту самую программу допишете, скорость компьютеров удвоится в полном сответствии с законом Тьюринга?
Сколько вы собираетесь поддерживать эту программу? Вам надо будет в ней баги исправлять и вносить бесчетное количество изменений следующие 5 лет? Ну, как это делает всем известная и всеми ругаемая фирма с ее ОС Windows? Если так, то о дизайне и архитектуре стоит думать _БОЛЬШЕ_, чем об оптимизации. Иначе сейчас Вы где-то можете сэкономить килоабайт, а через год потерять мегабакс.
Мое мнение: определенного рецепта нет. Оптимизировать надо там, где это необходимо.

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

TK>Если ты думаешь, что запустил профайлер, посмотрел на цифры и получил результат, в котором написано где и что надо поменять то, это не так. Как раз догадками будет будет оперировать программист. Профайлер для него эти цифры никак не проинтерпритирует.
Да уж, не проинтерпритирует. Голову никто не отменял. Только цифры профайлера достаточно точны чтобы точно выявить где нужно оптимизировать. И действовать не догадками, но разумом. А догадки — вещь нехорошая. Сам грешен, не пользовался профайлером(их еще тогда не было, или я о них не знал) или логами и оптимизировал по догадкам. Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит. А вот две предыдущей оптимизации уже непонятно, нужны ли они были, и вообще были ли оптимизациями — непонятно. Доказательств нет.

TK>Кроме того, профайлер сам вносит достаточную погрешность в измерения
Это хреновый профайлер, или неумение им пользоваться.

TK>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
Бывает. А вот для этого логи никто не отменял.
И вообще, в современном мире наиболее часто тормозным является БД. Обычно ее оптимизацией и оптимизацией качества и количества запросов все и обходится.

TK>Ошибки сами по себе не случаются. влада тому пример. данный пример замечательно показывает как незначительный просчет в дизайне может привести к тому, что приложение станет абсолютно не поддерживаемым.
Это не слишком показательный пример. У меня показательный пример был в моей первой программе. Целевыми компами были XT и 286. За плечами аж две книжки по Турбо-Паскалю. Программа достаточно большая. Загрузка формы в районе 5-6 секунд. При чтении с диска использовались BlockRead, и я грешил что это диск тормозит, чем и отмазывался. Дескать программа сложная. Смущало только большой промежуток времени между миганиями лампочки диска при чтении. Потом по мере появления опыта — я понял что тормозило перекатывание из памяти после чтения с BlockRead в родные паскалевские типыв условиях жуткой оптимизации формата файла, чтобы он меньше занимал места(сейчас такое кажется смешным потому такие вещи делаются часто и в лет) . Оптимизация файла была лишней.

GZ>>Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса.
TK>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?
Во-первых, хороший архитектор понимает две вещи, нужно уменьшать риски путем предварительных тестов, все не уменьшишь всегда что-нибудь останется. Во-вторых, хороших архитекторов немного. А в третьих — не везде они есть.

TK>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.

TK>А вот переделка ошибок дизайна в "большом" приложении может стоить очень дорого. Это, хорошо, если это поймали на этапе тестирования. А если в эксплуатации? Сколько будет стоить исправление ошибки?
+1

TK>Хотя, в целом интересное наблюдение... Похоже, что большинство местных посетителей начинают думать только после того, как написанные софт вернулся из QA... из разряда "и как-же мне это чудо теперь ускорить?"
Зависит от типа приложения. Если у тебя мат. рассчеты то это делается до QA в обязательном порядке.

С уважением, Gleb.

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

TK>ИХМО, Павел в первую очередь учит людей (студентов) думать. А просто программировать можно и по чукотски — что вижу то и пишу (для большинства задач этого впоне хватит). А если еще быстро печатать то, вообще супер будет

[flame] — как и вся тема.

Можно и по-чукотски, кто же против. Разные люди, разные подходы, быстро взял, быстро сделал, и комплексы не мучают (китай-индия), криво, но пурга сойдет, оленей дальше поведем, 100 долларов деньги большие. Есть и другие подходы. Я когда вижу профессионала, мне очень приятно, я выжму из этого человека все что только возможно, даже если его знания мне не пригодятся, и буду при этом молчать, человек сам расколется, знания без вез возможности передать другим — это вещь отрицательная по сути, я это хрошо понимат все у кого эти знания есть, у меня свои знания, а передать их некому и это тяготит. Ладно, проехали, возможно я что не понял в вашей месаге, и понял, наверное, привратно.
ЗЫ. В этой задаче Павел ничему и не учит, по моему дилетанскому мнению, это одна сплошная пальцевитость на локальной проблеме — читать по байтам или грузить блоки. У каждого есть свои задачи, решенные элегантным образом это не повод выносить тему в философию.

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

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

M>>На пустом месте проблема .
M>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

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

Абстракцию легко заменить на конкретную реализацию , а вот наоборот сложнее.

TK>ИХМО, Павел в первую очередь учит людей (студентов) думать. А просто программировать можно и по чукотски — что вижу то и пишу (для большинства задач этого впоне хватит). А если еще быстро печатать то, вообще супер будет

Думать — это хорошо. Студентов надо учить думать. Но надо и учить ПРАВИЛЬНО РАБОТАТЬ. Иначе будем как всегда (как при союзе) — все умные, но почему-то в дерьме.

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

VD>Здравствуйте, Pavel Dvorkin, Вы писали:

M>>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .

PD>>Естественно. Но я же не о нем

VD>А чем:
VD>

VD>char ch = file.ReadChar();
VD>

VD>отличается от использования потока?

Я имел ввиду что fopen fread это тоже абстракция , не имел ввиду какой то std::stream

Здравствуйте, Павел

С удовольствием прочел бурную дискуссию. Сейчас у нашей команды проблема производительности стоит остро. Расскажу все как есть. Мы занимаемся обработкой огромных потоков информации, которые поступают от крупнейшего бла-бла-бла. Работа одного из модулей состоит из чтения данных из файла, запись в БД, запуск нескольких SP на БД и последнее запись результатов снова в файлы. Модуль обязан работать быстро, качественно и далее по оранжевой книге...
Модуль написан на С++ и использует практически все "крутые фитчи" от STL, Boost, Log4cpp, DP, Oracle... Я бы сказал, что код написан не просто на высоком уровне, на высочайшем, так как приняты во внимания практически все рекомендации заслуженых профи в этих областях (Саттер, Мэйерс, Кайт...). Вобщем вы поняли, нарекания на дизайн не может быть, просто физически не к чему прикопатся.

Так вот, мы посчитали, что 25 тыс. загруженых (5Мб файл) записей из CDR-файлов(для тех кто с биллингом не работал, это такие CSV-файлы) с обработкой и последующей записью занимает 2 мин. 14 сек. Далее характеристики двух дней оптимизации:

Точка отчета:                                 2 мин. 14 сек.
(А)Очередь симметричных запросов:             2 мин. 05 сек.
(АР)Резервирование памяти, под 
    "узнаваемые" данные:                      2 мин. 00 сек.
(А)Замена map vector-м                        1 мин. 54 сек.
(АР)Замена строк хэшем                        1 мин. 30 сек.
(АР)Запись в файл через буфер строк,
    вместо записи vector-а строк в поток      42 сек (запись в 5 МБ в файл=0.05 сек)
(А+АР)далее...:                               15 сек

АР — архитектурное решение примененено,
А — применен алгоритм
Если раньше модуль накапливал данные днем и обрабатывал ночью, то теперь он все успевает, более того модуль отдает больше CPU времени для своих нужд. Для нас вышло, что выигрыш одной сек на операции — это выйгрыш ~12 мин в день. Это здорово, так как заказчики "писают кипятком", а "конкуренты кусают локти"

PS: Все началось с того, что мне сказали, что якобы кто-то где-то видел "крутую программу", которая выгружает 1 млн. записей в CSV-файл за 1 сек. Я не поверил, но призадумался.

PPS:
$uname -X
System = SunOS
Release = 5.9
KernelID = Generic_117171-08
Machine = sun4u
NumCPU = 20

$top
Memory: 160G real, 79G free, 60G swap in use, 101G swap free

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

TK>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?

Давай проведем эксперимент. Итак, код:

public abstract class LoaderBase : ILoader
{
    private const string s_SchemaResourceName = "Parus.MetadataModel.Model.TornadoMetadata.xsd";
    private static XmlSchema s_MetadataSchema;

    private static XmlSchema GetMetadataSchema()
    {
        if (s_MetadataSchema == null)
            using (Stream s = typeof (LoaderBase).Assembly.GetManifestResourceStream(s_SchemaResourceName))
                s_MetadataSchema = XmlSchema.Read(s, null);
        return s_MetadataSchema;
    }

    /// <summary>
    /// Смотри <see cref="ILoader.Load(string, IMetaResolver)"/>.
    /// </summary>
    public XmlDocument Load(string src, IMetaResolver resolver)
    {
        XmlValidatingReader valRdr = new XmlValidatingReader(new XmlTextReader(new StringReader(src)));
        valRdr.Schemas.Add(GetMetadataSchema());
        XmlDocument doc = new XmlDocument();
        doc.Load(valRdr);
        return doc;
    }
}

Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.
Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема. Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

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

AVK>Давай проведем эксперимент.

А можно и мне попробовать?

AVK>

AVK>public abstract class LoaderBase : ILoader
AVK>{
AVK>    /// <summary>
AVK>    /// Смотри <see cref="ILoader.Load(string, IMetaResolver)"/>.
AVK>    /// </summary>
AVK>    public XmlDocument Load(string src, IMetaResolver resolver)
AVK>    {
AVK>        XmlValidatingReader valRdr = new XmlValidatingReader(new XmlTextReader(new StringReader(src)));
AVK>        valRdr.Schemas.Add(GetMetadataSchema());
AVK>        XmlDocument doc = new XmlDocument();
AVK>        doc.Load(valRdr);
AVK>        return doc;
AVK>    }
AVK>}
AVK>

Выделенное жирным обязательно на каждом вызове Load делать?

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

E>Выделенное жирным обязательно на каждом вызове Load делать?

Да, ValidatingReader работает только в одну сторону.

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

TK>>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?

AVK>Давай проведем эксперимент. Итак, код:

Это ты про то, что если добавлять не схему а коллекцию схем то, это будет эффективнее?

AVK>Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.

Несколько порядков это в 100раз минимум. я правильно понял?

AVK>Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема.

Ты мне главное объясни — причем тут профайлер? Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать. Макаронным код она никак не сделает. Более того, в коллекцию можно будет добавить несколько схем что, может тоже пригодиться.

Или, ты каждый раз профайлер на этих строчках запускаешь? ИХМО, можно один раз понять (либо запомнить) а потом использовать.

В любом случае — как это относится к теме обсуждения?

PS
Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

PPS
AVK>Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

Тебя же вроде как не валили? Откуда негатив-то?

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

TK>Это ты про то, что если добавлять не схему а коллекцию схем то, это будет эффективнее?

Ага

AVK>>Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.

TK>Несколько порядков это в 100раз минимум. я правильно понял?

Точных цифр я уже не помню, но где то так.

AVK>>Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема.

TK>Ты мне главное объясни — причем тут профайлер?

Ни при чем. Вопрос в том как с таким бороться.

TK> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.

Все знать невозможно.

TK>В любом случае — как это относится к теме обсуждения?

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


TK>PS
TK>Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

Это GUI приложение. Никаких потоков там нет.

TK>PPS
AVK>>Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

TK>Тебя же вроде как не валили? Откуда негатив-то?

Нелюблю таких. Но это уже оффтоп.

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



настаиваю на введение трехбальной системы оценок в сторону юмора на rsdn.

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

TK>>Ты мне главное объясни — причем тут профайлер?
AVK>Ни при чем. Вопрос в том как с таким бороться.

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

TK>> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.
AVK>Все знать невозможно.

Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен :). В данном случае оптимизировать надо было только метод Load

TK>>В любом случае — как это относится к теме обсуждения?

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

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

TK>>PS
TK>>Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

AVK>Это GUI приложение. Никаких потоков там нет.

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


TK>>Тебя же вроде как не валили? Откуда негатив-то?
AVK>Нелюблю таких. Но это уже оффтоп.

А мне то зачем это выссказывать? Вон, про парус тоже иногда фигню всякую пишут. тебе это часто вспоминают?

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

TK>Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен . В данном случае оптимизировать надо было только метод Load

Конечно не надо тратить месяц и делать некую конкретную функцию в конкретном проекте быстрее в 100 раз, если за цикл работы она вызывается 2 раза и работает 0,001 сек.
Проблема возникает, когда такой код начинают реюзать в других проектах — в ситуациях когда он вызывается 1000000 раз.
А с первого взгляда не скажешь, да и не пишут в комментариях "эта ф-ция не оптимизировалась".

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

GZ>Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит.

Ну, такое только в сказке бывает. А теперь, представь что оптимизируется бизнес приложение проблемы с которым обнаружились только в pruduction и только под большой нагрузкой. Второго такого железа нет а запуск профайлера, на рабочей системе предполагает то, что больше половины пользователей не смогут ей пользоваться...

TK>>Кроме того, профайлер сам вносит достаточную погрешность в измерения
GZ>Это хреновый профайлер, или неумение им пользоваться.

Ну, например профилируем веб сайт... Второго такого железа у нас нет и потому профилируем по живому. Запустили профалер все начало тормозить, запросы начали отваливаться по таймауту. Что на это делают пользователи? делают рефреш на первую страницу. В итоге, мы получаем замечательную статистику для оптимизации первой страницы — нагрузка на которую в обычное время не такая уж и большая. И оптимизировать ее совершенно не нужно...

TK>>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
GZ>Бывает. А вот для этого логи никто не отменял. ;)

Гланое, что-бы они тормозить не начали ;)

TK>>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
GZ>Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.

Правильно. Потому Дворкин и пишет, что дума надо. Вполне возможно, что сортировка вообще не нужна если данные хранить в уже отсортированном виде :)

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

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

GZ>>Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит.
TK>Ну, такое только в сказке бывает.
Нее в жизни. У меня как только торможение появляется, так мыслей 10-20 сразу же, где это может быть. Половина из них — неправильные.

TK>А теперь, представь что оптимизируется бизнес приложение проблемы с которым обнаружились только в pruduction и только под большой нагрузкой. Второго такого железа нет а запуск профайлера, на рабочей системе предполагает то, что больше половины пользователей не смогут ей пользоваться...
TK>Ну, например профилируем веб сайт... Второго такого железа у нас нет и потому профилируем по живому. Запустили профалер все начало тормозить, запросы начали отваливаться по таймауту. Что на это делают пользователи? делают рефреш на первую страницу. В итоге, мы получаем замечательную статистику для оптимизации первой страницы — нагрузка на которую в обычное время не такая уж и большая. И оптимизировать ее совершенно не нужно...
Ну-ну-ну. Не надо по живому. Лучше организовать нагрузочное тестирование на левом железе. Некоторые проблемы выявишь сразу, будет меньше ответсвенной работы.

TK>>>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
GZ>>Бывает. А вот для этого логи никто не отменял.
TK>Гланое, что-бы они тормозить не начали
Смотря как напишешь. У меня одним пользователям так понравились мои дебужные логи, что они решили их не отключать. Нагрузка на логи не сравнить с нагрузкой на web-сайт.

TK>>>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
GZ>>Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.
TK>Правильно. Потому Дворкин и пишет, что дума надо. Вполне возможно, что сортировка вообще не нужна если данные хранить в уже отсортированном виде
Или наоборот. Окажется что quick sort хоть и тормозит, но выполняется раз в год и у него на входе 3 объекта. Хотя это действительно алгоритмическая оптимизация, и ею надо заниматься до реализации.

С уважением, Gleb.

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

PD>Следует ли из этого, что читать побайтно вообще нельзя ? Ни в коем случае!

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

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

TK>Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать.

Какие вещи? Читать блочно? А в институтах только этому учат или там рассматривают все возможные варианты? Я вот, например, сходу могу предложить с десяток способов как это можно сделать. В институте рассматриваются все эти способы, рассматриваются их достоинства и недостатки? Сравниваются ли эти способы в контексте конкретных приложений или только в контексте СКВВ? Делаются ли всегда однозначные выводы или многозначные? Чему собственно учат в институте по-твоему?

TK>Вобщем, не слушайте Влада — еще не того насоветует (он тут рядом вообще кончину Win32 предрекал

Да ты там тоже землицы в могилку побрасывал, так-что не надо

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

0rc>Далее характеристики двух дней оптимизации:

Интересная статистика.

Думаю таких примеров может каждый наприводить Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации. Вот от меня небольшой списочек.

1. Загрузка и обработка 3-х гигабайтного файла телефонных транзакций в БД. Примерно 11 млн записей. Переход на BULK INSERT (с самого начала не хотелось с ним связываться) — ускорение в 80 раз. Сокращение времени загрузки с 2.5 суток до 48 минут.
   
2. Перенос логики обработки данных одного отмороженного отчёта с C++ на T-SQL. Там надо было много и непонятно группировать. Были задействованы все возможные самые плохие практики T-SQL включая временные таблицы и циклы. Сокращение времени с 4-х часов до 18 минут за счёт исключения множественных обращений к серверу.
   
3. Расчёт начисления платежей. Переход с обработки данных record-by-record на обработку массивами. Опять же T-SQL. Использовалось много временных таблиц, но в расчётах ни одна запись не обрабатывалась индивидуально. Т.е. если что-то умножалось на 2, то это были десятки тысяч записей. Порядка двух десятков стадий вычислений. Количество master-records в основной таблице около полумиллиона. Сокращение работы с 40 минут до 2.5 минут.
   
4. Замена алгоритма сортировки большого списка документов (~50k) с честного алгоритма сортировки на единственный проход по заранее отсортированному списку по заранее определённым критериям. Было несколько секунд, стало незаметно на глаз.
   
5. Переход с поблочного чтения данных из файлов на отображаемые файлы. Увеличение скорости в 3 раза и как результат уменьшение скорости обновления данных с 20-25 минут, до 7-8. Но не тут-то было Всё замечательно работало на NT и жутко тормозило на W95. Проблема решилась тупым прогоном отображения через небольшой участок памяти.
   
6. Сокращение размера индекса в самопальной БД с 4-х байт до 3-х Экономия 100MB на диске, что позволило уложить базу данных на сидюк.
   
7. Использование в качестве данных при моделировании двух больших массивов. По сути, две громадные структуры, одна на начало такта, другая типа текущие данные. Синхронизация делалась простым memcpy. Для этого пришлось написать свой компилятор, который вкладывал туда даже то, что сегодня называется метадатой. Результат — конкуренты перестали заниматься подобными системами
   
8. Перекрытие и реализация своего собственного метода new типа как у Влада в статье про Quick Heap. Ускорение подготовки отчёта в десятки раз. Что-то там у борландовского хипа не сложилось тогда. Похоже, что от фрагментации у него крыша поехала.
   
9. В RFD (ну куда же без него ) замена рефлекшина на имит позволила сократить время маппинга в 3-5 раз и догнать по производительности датасеты и ридер.
   
10. Принудительная реаллокация памяти для stl вектора. Сокращение расходуемой памяти с 100 мег до 20-ти.

В принципе, последняя оптимизация была не столько оптимизацией, сколько фиксом стандартного stl'евского бага. Подобных мелких оптимизаций всегда много. Подавляющее большинство подобных вещей решается кеширование. Но это не очень интересно.

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

IT>

В RFD (ну куда же без него ) замена рефлекшина на имит позволила сократить время маппинга в 3-5 раз и догнать по производительности датасеты и ридер.
IT>

Принудительная реаллокация памяти для stl вектора. Сокращение расходуемой памяти с 100 мег до 20-ти.
IT>[/list]

IT>В принципе, последняя оптимизация была не столько оптимизацией, сколько фиксом стандартного stl'евского бага. Подобных мелких оптимизаций всегда много. Подавляющее большинство подобных вещей решается кеширование. Но это не очень интересно.

Таких списков можно насоставлять море. Дело то не в этом. Народ ругается похоже по другому поводу. Просто слово "ОПТИМИЗАЦИЯ" имеет несколько смысловых значений. На вскидку попытаюсь предложить несколько (применимо к разработки), сильно не критикуйте.

1. Оптимизация, которая делается только тогда когда что-то (модуль программный) работает не так, как нам это нужно (пользователям). Т.е. тормозит, память отжирает и т.д. Ищем узкие места профайлером. То, за что агитирует со страшной силой Влад2 (кстати, а почему 2???)
2. Выбор оптимальных путей кодирования. То есть когда нужно использовать ArrayList, а когда LinkedList, а когда вообще HashMap. Ну это к примеру. Причем делаем мы это неосознанно.
3...
4...

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

P.S. А может тут еще какая-то засада?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

IT>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Следует ли из этого, что читать побайтно вообще нельзя ? Ни в коем случае!

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

Может быть, ты и прав. Кстати, если MS реализует свою файловую систему а ля SQL сервер, то между чтением побайтно и поблочно, с одной стороны, и сервером БД просто разницы не будет , потому как ФС и будет БД

Если же оставаться на нынешней стадии, то все же ИМХО скорость БД будет поменьше. Подчеркиваю — ИМХО, это не личный опыт, а скорее отзывы, какие я получил. Я, когда над своим проектом начал работать (а было это 4 года назад) первым делом задал вопрос в фидо конференции по БД — так и так, есть такие-то данные, можно ли с помощью БД получить доступ за 50-70 мсек, если да — какую БД посоветуете ? Ответ был единодушный — нет. Может, они не правы были, к тому же с тех пор прошло 4 года...

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

TK>Этот случай надо запомнить.

Все не упомнишь.

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

Можно. Только это не помогло бы. Каким бы не был медленным валидатор, он явно не должен тратить несколько секунд на валидацию пары десятком килобайтных XML-файлов.

TK>>> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.
AVK>>Все знать невозможно.

TK>Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен . В данном случае оптимизировать надо было только метод Load

А никто и не занимался. Тормозила определенная операция. Запустили профайлер — обнаружили что метод XmlSchemaCollection.Add жрет 99% времени, что, мягко говоря, странно. Полезли в рефлектор, удивились еще больше. Поправили и получили ускорение на пару порядков минимум.

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

TK>Именно по этому, надо нормально писать даже самые маленькие кусочки.

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

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

Вот, золотые слова.

AVK>>Это GUI приложение. Никаких потоков там нет.

TK>Сегодня нет, а если завтра появятся?

Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.

TK>>>Тебя же вроде как не валили? Откуда негатив-то?
AVK>>Нелюблю таких. Но это уже оффтоп.

TK>А мне то зачем это выссказывать? Вон, про парус тоже иногда фигню всякую пишут. тебе это часто вспоминают?

А я не тебе, я тому товарищу, просто напрямую обратится не имею возможности.

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

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

И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?

Иногда (в моей задаче, к примеру) надо бывает оптимизировать по скорости, а с памятью меня никто особенно не напрягал. Я об этом, кстати, говорил — занял бы еще несколько десятков или сотню Мб — никто бы слова не сказал, а вот за 200 мсек на запрос выгнали бы. А иногда — прямо наоборот, скорость вообще несущественна (та же ICQ, к примеру , где ее вообще по скорости можно оптимизировать, когда скорость определяется интернетом, да и там в основном SMS шлются — short пакеты, так сказать), а вот памяти я ей бы позволил заниимать не более 500 Кбайт при обычной работе (ну а при прочих действиях, так и быть, 1 Мб позволил бы . (И то, 500 Кбайт — это снисходя к современным аппетитам, реально ей и 100 не надо . Потому что в данном случае это мелкая приблуда на моем PC, и ее наличие я вообще в смысле потребления памяти должен просто не замечать.

Кстати, у VC компилятора есть несколько базовых режимов оптимизации — Minimal size, Maximum Speed. К чему бы это ? . Они что-то тоже не хотят сказать, что важнее.

Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Таких списков можно насоставлять море.

Так вот и надо их насоставлять. И боюсь блочного чтения там может и не оказаться

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

PD>И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?

Но тогда как следовать твоему лозунгу?

PD>Иногда (в моей задаче, к примеру) надо бывает оптимизировать по скорости, а с памятью меня никто особенно не напрягал. Я об этом, кстати, говорил — занял бы еще несколько десятков или сотню Мб — никто бы слова не сказал, а вот за 200 мсек на запрос выгнали бы. А иногда — прямо наоборот, скорость вообще несущественна (та же ICQ, к примеру , где ее вообще по скорости можно оптимизировать, когда скорость определяется интернетом, да и там в основном SMS шлются — short пакеты, так сказать), а вот памяти я ей бы позволил заниимать не более 500 Кбайт при обычной работе (ну а при прочих действиях, так и быть, 1 Мб позволил бы . (И то, 500 Кбайт — это снисходя к современным аппетитам, реально ей и 100 не надо . Потому что в данном случае это мелкая приблуда на моем PC, и ее наличие я вообще в смысле потребления памяти должен просто не замечать.

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

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

AVK>>>Это GUI приложение. Никаких потоков там нет.

TK>>Сегодня нет, а если завтра появятся?

AVK>Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.

Вот индус, написавший код XmlSchemaCollection, тоже так же думал, что никто часто схемы грузить не будет

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

PD>Если же оставаться на нынешней стадии, то все же ИМХО скорость БД будет поменьше. Подчеркиваю — ИМХО, это не личный опыт, а скорее отзывы, какие я получил. Я, когда над своим проектом начал работать (а было это 4 года назад) первым делом задал вопрос в фидо конференции по БД — так и так, есть такие-то данные, можно ли с помощью БД получить доступ за 50-70 мсек, если да — какую БД посоветуете ? Ответ был единодушный — нет. Может, они не правы были, к тому же с тех пор прошло 4 года...
Используя локальные БД и низкоуровневое API легко. По сути ни чем не отличающейся от прямого доступа. Но легко строить объектную надстройку.

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

P>Здравствуйте, Pavel Dvorkin, Вы писали:

P>[offtopic]
P>Павел, коллега, вы похоже пытаетесь вывести некие универсальные законы которые должно воспринимать как некие откровения. Может быть мой опыт программирования и не столь велик и писать программы я стал в зрелом 32-х летнем возрасте, но если бы мне пришлось мучиться такими парадигмами, то уверен, что дальше задачи написания программы Hello_World.exe дело бы не сдвинулось. У меня нет опыта преподавания, потому мое мнение сугубо дилетанское — нет нужды загружать чужие мозги задачами которые не кричат, у всех своя голова, как и кто будет решать конкретную задачу зависить от обстоятельств и от человека.

Золотые слова.

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

Программирование — это прикладная дисциплина, индустрия, тут надо больше делать, чем думать.(Я не говорю, что не надо думать, просто обычно надо думать сугубо практически, над конкретной задачей)

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

TK>Этот случай надо запомнить. Хотя, можно было-бы и на этапе проектирования прикинуть, что валидация сложного XML документа может быть достаточно ресурсоемким заданием.

Запомнить нужно не этот случай, а то что проблемы могут не поддаваться учату зараннее. И профайлер позволяет их найти.

Как, по-твоему, АВК мог б узнать об этой проблеме не включая профайлер? Его код ведь практически идеален. Проблема в бибилиотеке.

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

PD>...что лучше : список или массив ?

А что у нас уже массив списком не является?

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

PD>Кстати, у VC компилятора есть несколько базовых режимов оптимизации — Minimal size, Maximum Speed. К чему бы это ? . Они что-то тоже не хотят сказать, что важнее.

А ты их переключи, и вместе посмеемся над разницей.

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

0rc>Так вот, мы посчитали, что 25 тыс. загруженых (5Мб файл) записей из CDR-файлов(для тех кто с биллингом не работал, это такие CSV-файлы) с обработкой и последующей записью занимает 2 мин. 14 сек. Далее характеристики двух дней оптимизации:
0rc>

0rc>Точка отчета:                                 2 мин. 14 сек.
0rc>(А)Очередь симметричных запросов:             2 мин. 05 сек.
0rc>(АР)Резервирование памяти, под 
0rc>    "узнаваемые" данные:                      2 мин. 00 сек.
0rc>(А)Замена map vector-м                        1 мин. 54 сек.
0rc>(АР)Замена строк хэшем                        1 мин. 30 сек.
0rc>(АР)Запись в файл через буфер строк,
0rc>    вместо записи vector-а строк в поток      42 сек (запись в 5 МБ в файл=0.05 сек)
0rc>(А+АР)далее...:                               15 сек
0rc>

0rc>АР — архитектурное решение примененено,
0rc>А — применен алгоритм
0rc>Если раньше модуль накапливал данные днем и обрабатывал ночью, то теперь он все успевает, более того модуль отдает больше CPU времени для своих нужд. Для нас вышло, что выигрыш одной сек на операции — это выйгрыш ~12 мин в день. Это здорово, так как заказчики "писают кипятком", а "конкуренты кусают локти"

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

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

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

AVK>Можно. Только это не помогло бы. Каким бы не был медленным валидатор, он явно не должен тратить несколько секунд на валидацию пары десятком килобайтных XML-файлов.

Извини, я так не пойму к чему ты все это говоришь? Если на жизнь жалуешься то, это не ко мне...
Ты привел свой пример здесь

Автор: AndrewVK
Дата: 01.11.05

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

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

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

TK>>Именно по этому, надо нормально писать даже самые маленькие кусочки.

AVK>Павел же понимает под эффективностью потребление процессора и памяти, причем никак не хочет сказать что важнее.

Это от ситуации зависит. Иногда, важнее надежность Или, у тебя универсальное решение есть?

TK>>Сегодня нет, а если завтра появятся?

AVK>Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.

Сделай readonly поле которое будет инициализироваться методом GetMetadataSchema. Даже, один LOC съэкономить можно. Что до того, что производительность ухудшит так, если есть два варианта производительность vs надежность то, лучше выбирать надежность (если конечно, софт не одноразовый)

AVK>А я не тебе, я тому товарищу, просто напрямую обратится не имею возможности.

Хочешь, я адрес дам куда жаловаться?

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

IT>Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.

А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?

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


КДВ>>Таких списков можно насоставлять море.

IT>Так вот и надо их насоставлять. И боюсь блочного чтения там может и не оказаться

А это уже зависит от предметной области, в которой человек силен и разбирается лучше всего. Я, к примеру, буду упор на структуру БД делать в первую очередь. Твоя очередь...

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

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?

AVK>Но тогда как следовать твоему лозунгу?

Какому лозунгу ? Я 33 раза говорил, что ни к какой оптимизации всего и вся я не призываю и 100 раз говорил, что истина конкретна. Если ты где-нибудь найдешь, что я призывал любой ценой и все, что угодно оптимизировать — покажи.

AVK>Здорово. А если еще вспомнить, что помимо памяти и процессора есть еще ряд немаловажных критериев и подставить их в вышеотквоченое, то спорить будет вобще не о чем.

Вообще-то да.

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


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

NC>Программирование — это прикладная дисциплина, индустрия, тут надо больше делать, чем думать.(Я не говорю, что не надо думать, просто обычно надо думать сугубо практически, над конкретной задачей)

Ну вот, дошли до точки. Оказывается, программисту надо больше делать, чем думать. А если думать — то только сугубо практически. И учить студентов думать я не должен. Все ясно.

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

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

IT>>Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.

IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?

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

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

[ваш флейм]
PD>Ну вот, дошли до точки. Оказывается, программисту надо больше делать, чем думать. А если думать — то только сугубо практически. И учить студентов думать я не должен. Все ясно.

[мой флейм]
Павел, одни преподаватели байки про свое бурное героическое прошлое гонят, как я на коленчке дырки на перфокарте колол и весь в синячках ходил и как я программку дипломную писал или как я на синтез хыфы-трицикло-мыгы-тетрагыгы фенилтетраметанана 140 часовой проводил будучи аспирантом и жил в лаборатории месяц безвылазно, другие не вещают, а бьют смертным боем несчастных студентов. К одним ходят на экзамет как на праздник, к другим идут как твари на закланье. Ни те не другие не учат, словеса которые произносят ученые мужи теряются в стенах БХА-БФА и прочих аудиториях, "покложить на них всех с прибором", вот единственная задача студента. Когда интересно, тогда их слушаешь, когда не интересно — спишь или в шахматы играешь. Реально учатся уже после получения диплома, на этот раз, действительно на совесть, база есть, дальше сам двигайся. База, как ни пародоксально, это не акадимические мужи с их бу-бу-бу, база это твои чистолюбивые и абициозные сокурстники и та среда которая заставляет тебя быть лучше других хоть в чем-то.

P>Павел, одни преподаватели байки про свое бурное героическое прошлое гонят, как я на коленчке дырки на перфокарте колол и весь в синячках ходил и как я программку дипломную писал или как я на синтез хыфы-трицикло-мыгы-тетрагыгы фенилтетраметанана 140 часовой проводил будучи аспирантом и жил в лаборатории месяц безвылазно, другие не вещают, а бьют смертным боем несчастных студентов. К одним ходят на экзамет как на праздник, к другим идут как твари на закланье. Ни те не другие не учат, словеса которые произносят ученые мужи теряются в стенах БХА-БФА и прочих аудиториях, "покложить на них всех с прибором", вот единственная задача студента. Когда интересно, тогда их слушаешь, когда не интересно — спишь или в шахматы играешь. Реально учатся уже после получения диплома, на этот раз, действительно на совесть, база есть, дальше сам двигайся. База, как ни пародоксально, это не акадимические мужи с их бу-бу-бу, база это твои чистолюбивые и абициозные сокурстники и та среда которая заставляет тебя быть лучше других хоть в чем-то.

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

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

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

Преподователь от Бога, особая категория профессионалов. Начнешь считать их, и пальцев одной руки хватит. Истинное счасть учиться у этих людей. Сдется мне, что количество их величина постояная и не от чего не зависящая.

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

VD>Видимо если вместо строк попользовать буферы в стеке, то приложение начнет вознващать время процессору (ну, давать отрицальные величины по времени)

В точку. Мы иногда так и отшучиваемся — еще чуть-чуть оптимизации и модуль будет работать в будущем

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

IT>Думаю таких примеров может каждый наприводить Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.
Был написан модуль, делающий посимвольный парсинг небольшого файла (что-то типа хмл), представление его в обьектном виде, интерфес для программной правки обьекта (или создание с нуля) и запись в файл. Файл свободно помещался в памяти.
Профайлер показал мелкие недочеты с моей стороны и главное то, что куча времени тратилась на оператор вывода символа в поток:

outstream << ch;

Анализ кода библиотеки показал, что там куча такого что мне не нужно. Заменил на

outbuffer++ = ch;

и експоненциальную реалокацию буфера.

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

IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?

А что говорить тут? Ты все правильно написал:
1. Bulk execute у нас уже был. Поэтому основных проблем не возникло. Хочу остановиться по подробнее на этом. Мы написали свой аналог OCCI, назвали его OCCIX. В основном преследовались две цели: (1) Уйти от OCI и CC к GCC 3.x и объектному интерфейсу. (2) Получить открытый исходник OCCIX. Поскольку полностью все вызовы, функции, параметры, классы и т.д. были одинаковы с OCCI. Мы получили полный аналог OCCI в плане интерфейса. Да и разработка не больно много заняла — всего неделя. Были мелкие ошибки — например, порядок байт в слове различен — но это быстро выявилось, да и ошибок было таких 1-2. Плюс получился очень интересный эффект — после разработки "велосипеда" мы имели по нем документацию на 800 стр.
2. PL-SQL нам так же хорошую службу сослужил. В другом модуле у нас было множество функций, написаных на ProC с ними постоянно в режиме "спагетти-кода" взаимодействовало где-то 10-15 Си-функций: свои велосипеды контейнеров на Си и все такое прочее. Было принято волевое решение — переписать модуль на С++ с использованием STL: в коде стали вырисовыватся объекты и слои. После оказалось, что слои полностью независимы. Итог: один из слоев мы перенесли полностью в PL-SQL. Сам исходный код модуля значительно уменьшился и стал намного лучше читатся.
3. Насчет временных таблиц — мы пришли к этому сразу (до стадии разработки). По началу меня бесило работа с временной таблицей на 130 колонок. Но после исследования (тут надо сказать о некоторой безолаберности в отношении моих предшественников: на 140 таблиц не было ни грамма документации) самой практики взаимодействия модулей. Конечно после 3G-систем, где все взаимодействие было через метаданные, абстракции и слои в БД — решение временной таблицы на 130 колонок, вначале смахиволо на идиотизм. Но после я разобрался почему такое решение было принято.
4. По поводу сортировки. Был один тонкий момент — перед выгрузкой нам подребовалось отсортировать курсор по колонке. Поскольку все тестировалось на тестовом сервере — мы физически не могли на тестовом сервере воспроизвести такую ситуацию, — у нас не было доступа к NE. Мы могли только сделать мелкий тесты регрессии на отдельных схемах. Когда же мы запустили на продакшене — оказалось, что сортировка курсора значительно тормозит — и нам пришлось отказатся от нее.
5. Отображаемые файлы у нас стоят на повестки дня — если понадобится еще увеличить производительность, то это следующий наш "козырь в борьбе за выживание". Пока мы их не применяли.

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

IT>>Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.

IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?

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

Из комплексных оптимизаций...

Массовая обработка объектов в БД. Начальное время работы — порядка 4 часов. Требуемое время работы — 20 минут.
— Замена сервера и RAID-массива — стало 1.5 часа
— Убрали дублирующие перерасчеты — примерно 1 час
— Изменили алгоритмы обработки с общих на частные случаи, основанные на полученной информации о характере обрабатываемых объектов — стало 30 минут
— Запуск обработки в несколько потоков — 19 минут (но т.к. все остальные процессы стали притормаживать, от этого отказались)
— Изменение размера страницы сервера на 8к — стало 19 минут. Т.к. уложились в тербуемое время, оптимизацию остановили.

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

TK>Так кто говорит, что надо сразу делать все опитимизации.

Пишите свои программы эффективно, господа! По крайней мере настолько, насколько это возможно!

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

А что, с этим кто то спорит?

AVK>>Павел же понимает под эффективностью потребление процессора и памяти, причем никак не хочет сказать что важнее.

TK>Это от ситуации зависит. Иногда, важнее надежность

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

AVK>>Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.

TK>Сделай readonly поле которое будет инициализироваться методом GetMetadataSchema. Даже, один LOC съэкономить можно. Что до того, что производительность ухудшит так, если есть два варианта производительность vs надежность то, лучше выбирать надежность (если конечно, софт не одноразовый)

Ладно, согласен. Все равно речь не об этом, да и код в реальном проекте несколько другой.

AVK>>А я не тебе, я тому товарищу, просто напрямую обратится не имею возможности.

TK>Хочешь, я адрес дам куда жаловаться?

Не надо.

От всего топика возникает желание написать статью, которая бы описывала оптимизацию какого нить реального приложения. Типа как у Криса Касперски.

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

P>[мой флейм]
P>[ skipped ]

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