VS2005, с++ проект. Работа с сетью через winpcap.
Заморочка (суть не важно, для полноты картины упоминаю): большое время между отправкой пакетов (порядка 50 мс). Тестовые примеры показали, что можно добиться единиц мс.
Опыт работы с профайлером небольшой, по-этому прошу помощи.
Его результат:
То, что pcap_next_ex() виновник всех бед, это понятно. Там в цикле одном она постоянно вызывается на предмет проверки приходящих пакетов. Локальное измерение показало, что именно это место фиксить, реже вызываеть ее.
Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
Здравствуйте, oziro, Вы писали:
O>Привет!
O>Извиняюсь, если не в тот форум
O>VS2005, с++ проект. Работа с сетью через winpcap. O>Заморочка (суть не важно, для полноты картины упоминаю): большое время между отправкой пакетов (порядка 50 мс). Тестовые примеры показали, что можно добиться единиц мс.
O>Опыт работы с профайлером небольшой, по-этому прошу помощи. O>Его результат: O>
O>То, что pcap_next_ex() виновник всех бед, это понятно. Там в цикле одном она постоянно вызывается на предмет проверки приходящих пакетов. Локальное измерение показало, что именно это место фиксить, реже вызываеть ее.
O>Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
а какой профилер?
если он показывает процессорное время, то это одно, а общее — другое.
как я помню, GetMessage ждет прихода сообщения. соответственно и время
Здравствуйте, Сергей Мухин, Вы писали:
СМ>обана. а я думал там его нет. как его использовать? вызвать?
Tools > Perfomance tolls > Perfomance Wizard. Он содается то ли подпроект, толи еще что то. Появвляется Perfomance Explorer, там из контекстного меню вызвать Launch. Вот такое шаманство
Здравствуйте, oziro, Вы писали:
СМ>>обана. а я думал там его нет. как его использовать? вызвать?
O>Tools > Perfomance tolls > Perfomance Wizard. Он содается то ли подпроект, толи еще что то. Появвляется Perfomance Explorer, там из контекстного меню вызвать Launch. Вот такое шаманство
У меня в меню Tools нет Perfomance tools и уж тем более что там далее. У Вас мб что-ниб еще установлено кроме msdev?
Здравствуйте, Сергей Мухин, Вы писали:
СМ>У меня в меню Tools нет Perfomance tools и уж тем более что там далее. У Вас мб что-ниб еще установлено кроме msdev?
About:
Microsoft Visual C# 2005
Microsoft Visual C++ 2005
Microsoft Visual Web Developer 2005
Microsoft Visual Studio 2005 Team Edition for Software Architects
Microsoft Visual Studio 2005 Team Edition for Software Developers
Microsoft Visual Studio 2005 Team Edition for Software Testers
Crystal Reports for Visual Studio 2005
Здравствуйте, Сергей Мухин, Вы писали:
СМ>У меня в меню Tools нет Perfomance tools и уж тем более что там далее. У Вас мб что-ниб еще установлено кроме msdev?
К сожалению, профайлер идет только в составе MS Visual Studio 2005 Team System (Team Editions),
в VS 2005 Professional и Standard Editions профайлера нет.
Здравствуйте, Alex_Avr, Вы писали:
A_A>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>У меня в меню Tools нет Perfomance tools и уж тем более что там далее. У Вас мб что-ниб еще установлено кроме msdev?
A_A>К сожалению, профайлер идет только в составе MS Visual Studio 2005 Team System (Team Editions), A_A>в VS 2005 Professional и Standard Editions профайлера нет.
O>То, что pcap_next_ex() виновник всех бед, это понятно. Там в цикле одном она постоянно вызывается на предмет проверки приходящих пакетов. Локальное измерение показало, что именно это место фиксить, реже вызываеть ее.
Не факт.
O>Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
То, что у вас показывается — процент нахождения в функции от времени работы программы. Это не означает, что эта функция — виновник ваших бед. Для того, чтобы сделать вывод, нужно иметь статистику по выполнению подфункций. Вполне вероятно, что большую часть времени pcap_next_ex проводит либо в WaitFor....Object, либо в DeviceIoControl, ожидая завершения IRP и не потребляя при этом никаких процессорных ресурсов. Что до GetMessage — так оно и есть.
В общем, читайте http://www.citforum.ru/book/optimize/chapter1.shtml
Здравствуйте, oziro, Вы писали:
O>Привет!
O>Извиняюсь, если не в тот форум
O>VS2005, с++ проект. Работа с сетью через winpcap. O>Заморочка (суть не важно, для полноты картины упоминаю): большое время между отправкой пакетов (порядка 50 мс). Тестовые примеры показали, что можно добиться единиц мс.
O>Опыт работы с профайлером небольшой, по-этому прошу помощи. O>Его результат: O>
O>То, что pcap_next_ex() виновник всех бед, это понятно. Там в цикле одном она постоянно вызывается на предмет проверки приходящих пакетов. Локальное измерение показало, что именно это место фиксить, реже вызываеть ее.
O>Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
попробуй изменить "read timeout" при вызове pcap_open
m_pHAdapter = pcap_open( szDevice, // name of the device
MAX_ADAPTER_PACKET_SIZE, // portion of the packet to capture
// 65536 guarantees that the whole packet
// will be captured on all the link layers
0, // PCAP_OPENFLAG_PROMISCUOUS,
1, // read timeout
NULL, // authentication on the remote machine
m_szError );
Здравствуйте, Arkady Palarya, Вы писали:
AP>попробуй изменить "read timeout" при вызове pcap_open
1 стояла.
Там забавней штука. Если сделать pcap_setfilter() с парой-тройкой полей вида "ether[16:2] = 0xAAAA", то pcap_next_ex начинает работать дольше, чем если фильтр не ставить...
Вообщем, спс за ответ.
Здравствуйте, Andrew S, Вы писали:
O>>То, что pcap_next_ex() виновник всех бед, это понятно. Там в цикле одном она постоянно вызывается на предмет проверки приходящих пакетов. Локальное измерение показало, что именно это место фиксить, реже вызываеть ее.
AS>Не факт.
O>>Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
AS>То, что у вас показывается — процент нахождения в функции от времени работы программы. Это не означает, что эта функция — виновник ваших бед. Для того, чтобы сделать вывод, нужно иметь статистику по выполнению подфункций. Вполне вероятно, что большую часть времени pcap_next_ex проводит либо в WaitFor....Object, либо в DeviceIoControl, ожидая завершения IRP и не потребляя при этом никаких процессорных ресурсов. Что до GetMessage — так оно и есть. AS>В общем, читайте http://www.citforum.ru/book/optimize/chapter1.shtml
Частное мнение: все книжки, автором которых является товарищи Крис Касперски — банальщина, графоманство и пустая трата времени/денег. По крайней мере те, которые я читал — например, эта
. Еще у меня как-то вызвала умиление статья товарища Касперски, в которой он рассказывал про то, что он изобрел сортировку за O(N) — сортировку подсчетом. После этих двух инцидентов я не могу относиться к его творчеству серьезно. ПТУ-шничество какое-то.
It's kind of fun to do the impossible (Walt Disney)
AS>>То, что у вас показывается — процент нахождения в функции от времени работы программы. Это не означает, что эта функция — виновник ваших бед. Для того, чтобы сделать вывод, нужно иметь статистику по выполнению подфункций. Вполне вероятно, что большую часть времени pcap_next_ex проводит либо в WaitFor....Object, либо в DeviceIoControl, ожидая завершения IRP и не потребляя при этом никаких процессорных ресурсов. Что до GetMessage — так оно и есть. AS>>В общем, читайте http://www.citforum.ru/book/optimize/chapter1.shtml
AA>Частное мнение: все книжки, автором которых является товарищи Крис Касперски — банальщина, графоманство и пустая трата времени/денег. По крайней мере те, которые я читал — например, эта
. Еще у меня как-то вызвала умиление статья товарища Касперски, в которой он рассказывал про то, что он изобрел сортировку за O(N) — сортировку подсчетом. После этих двух инцидентов я не могу относиться к его творчеству серьезно. ПТУ-шничество какое-то.
Это все хорошо. По теме то есть что сказать, или просто так, увеличиваем энтропию?
Здравствуйте, oziro, Вы писали:
O>Меня смущает GetMesageA. Это вроде одна из виндовых функций для обработки оконных сообщений. Как мне реагировать на ее 42% time? Интуиция подсказывает, что не важно это. Тем более, она в другом потоке где интерфейс...
Это и есть нормальное состояние потока, когда в очереди нет сообщений — спать внутри GetMessage. Но у неё внутрях много чего происходит (вызовы sendmessage от других процессов, хуки, if (rand()==0x666) bsod()), поэтому трудно сказать, занята она ожиданием или там что-то делается. Надо смотреть на сопутствующие, например на оконную процедуру. Можно поменять её на PeekMessage, которая не ждет, а сразу выходит, а Sleep делать самому, тогда в случае тормозов внутри PeekMessage они сразу же проявятся.
Здравствуйте, Andrew S, Вы писали:
AS>Это все хорошо. По теме то есть что сказать, или просто так, увеличиваем энтропию?
Все, что я сказал, непосредственно относится к теме беседы. Ты порекомендовал книгу, которая мне не кажется достойной. Я экономлю время и деньги людям, делясь с ними своим мнением. Если кому-то мое мнение неинтересно — замечательно. Найдутся и те, кому оно интересно.
По поводу энтропии — все мы ее увеличиваем. И я, и ты.
It's kind of fun to do the impossible (Walt Disney)
AS>>Это все хорошо. По теме то есть что сказать, или просто так, увеличиваем энтропию?
AA>Все, что я сказал, непосредственно относится к теме беседы. Ты порекомендовал книгу, которая мне не кажется достойной. Я экономлю время и деньги людям, делясь с ними своим мнением. Если кому-то мое мнение неинтересно — замечательно. Найдутся и те, кому оно интересно.
Я "порекомендовал" не книгу, а ссылку на статью, где описываются вполне банальные приемы профайлинга. Крис там ничего нового не излагает, но и откровенной лажи тоже нет — все вполне приемлемо. Если вы не потрудились ее прочитать — ну, это ваше право. Тем не менее, см. ниже.
AA>По поводу энтропии — все мы ее увеличиваем. И я, и ты.
Критикуя — предлагай. Т.о. энтропию в данном случае увеличили лишь вы
Здравствуйте, Andrew S, Вы писали:
AS>Я "порекомендовал" не книгу, а ссылку на статью, где описываются вполне банальные приемы профайлинга. Крис там ничего нового не излагает, но и откровенной лажи тоже нет — все вполне приемлемо. Если вы не потрудились ее прочитать — ну, это ваше право. Тем не менее, см. ниже.
И многое-многое другое. Ну да, все на английском. Хочется на русском — приходится читать всякую каку.
AS>Критикуя — предлагай.
А вот это — согласен. Я согласен с тобой, что надо смотреть, что выполняется под GetMessage. У товарища программа проводит все время на ожидании, судя по всему. Кроме того, из оригинального поста совершенно непонятно, какова загрузка процессора во время выполнения и что вообще хочется оптимизировать. Просто чтобы работало быстрее?
> Т.о. энтропию в данном случае увеличили лишь вы
Да ладно. Ты тоже пофлеймить любитель.
P.S. На "ты" обращаюсь принципиально — не люблю выканья в конференциях.
It's kind of fun to do the impossible (Walt Disney)
AS>>Я "порекомендовал" не книгу, а ссылку на статью, где описываются вполне банальные приемы профайлинга. Крис там ничего нового не излагает, но и откровенной лажи тоже нет — все вполне приемлемо. Если вы не потрудились ее прочитать — ну, это ваше право. Тем не менее, см. ниже.
AA>Если ты щелкнешь по своей же ссылке http://www.citforum.ru/book/optimize/chapter1.shtml — то увидишь, что это глава из книги:
Ну и? Это же не _вся_ книга, а вполне себе отдельный текст. Для новичка — очень кратко и понятно.
AA>Я разрабатываю средства измерения производительности профессионально не первый год. Так вот — книжка плохая. Есть гораздо более полезные ресурсы:
Повторюсь, меня книга как таковая в данном случае не интересует. В данном случае указанная статья (пусть она и является главой из книги) вполне неплохо выполняет свои функции вводной информации. В общем, честно, я не вижу смысла продолжать дискуссию в этом ключе. Если есть что сказать автору ветки по его проблеме — велкам. Если есть претензии к указанной статье кроме "книга г-на Касперски это гуано" — тоже интересно. А иначе смысл?
Здравствуйте, Andrew S, Вы писали:
AS>>>Я "порекомендовал" не книгу, а ссылку на статью, где описываются вполне банальные приемы профайлинга. Крис там ничего нового не излагает, но и откровенной лажи тоже нет — все вполне приемлемо. Если вы не потрудились ее прочитать — ну, это ваше право. Тем не менее, см. ниже.
AS>Ну и? Это же не _вся_ книга, а вполне себе отдельный текст. Для новичка — очень кратко и понятно.
Ни фига себе кратко... По поводу статья это или книга — мно по барабану, пусть выдержка из книги. Ты начал утверждать, что это статья, и хотя мне и все равно — не смог удержаться от того, чтобы не подколоть. Мне в твоем первом сообщении твой тон как-то не понравился — отсюда и беседа в неконструктивном ключе.
AS>Повторюсь, меня книга как таковая в данном случае не интересует. В данном случае указанная статья (пусть она и является главой из книги) вполне неплохо выполняет свои функции вводной информации. В общем, честно, я не вижу смысла продолжать дискуссию в этом ключе. Если есть что сказать автору ветки по его проблеме — велкам.
Автору много чего сказали и спросили — ход за ним. Профилировка — интерактивный процесс, просто так по звездам не получится.
> Если есть претензии к указанной статье кроме "книга г-на Касперски это гуано" — тоже интересно. А иначе смысл?
Я как-то раньше уже упоминал подробный список замечаний к данной книге и статье-которая-на-самом-деле-выдержка-из-книги. Это было оформлено в виде письма Крису — ответа от него не последовало. Копирую здесь:
Привет, Крис!
Меня зовут Алексей Александров, я недавно купил твою (ничего что на Ты?)
книгу "Техника оптимизации программ: эффективное использование памяти" и
прочитал ее от корки до корки. По ходу дела возникли некоторые вопросы и
замечания.
Итак, вот что я заметил во время прочтения книги:
1. В книге упоминается устаревшая версия профилировщика VTune. На
сегодняшней день текущей является версия VTune 7.1. Самым большим
расхождением с 5-м является то, что теперь не поддерживается режим эмуляции
работы процессоров. Мне сложно сказать почему так вышло, Официальная точка
зрения, что конвейеры Pentium 4 стали слишком сложными, чтобы их можно было
эмулировать. В любом случае, в книге лучше ориентироваться на 7-й VTune,
который зато имеет много других дополнительных функций, в частности,
поддерживает современные процессоры.
2. стр.259, второй параграф снизу: "...при частных кэш-промахах она
работает..." должно быть, видимо "...при частых кэш-промахах она
работает..."
3. стр.270. Политика записи должна называться Write Through, а не Write
True.
4. стр.239. Письмо от Дмитрия Коробицына по поводу сортировки float-ов
методом прямого отображения. Предложение "неплохо бы проверить, чем
закончилось выделение 16 Гбайт памяти" звучит несколько странно. В общем-то,
можно и не проверять, ибо как выделить 16 Гбайт памяти на x86 не получится.
Упоминание про возможность использования DMA для обнуления памяти тоже
смешно. Тем более, что ближе к концу книги ты сам пишешь про этот миф с DMA.
Кстати, одним из возможных трюков для уменьшения потребляемой памяти при
сортировке методом прямого отображения является выделение памяти по
требованию. То есть, выделяем память через VirtualAlloc с флагом
MEM_RESERVE, а при сортировке ловим исключения. Если приходит Access
Violation при обращение к нашей области памяти, то делаем
VirtualAlloc(MEM_COMMIT) для одной странички (для той, на которой
расположена ячейка памяти, при обращении к которой произошел сбой), обнуляем
ее и возвращаем EXCEPTION_CONTINUE_EXECUTION, т.е. пытаемся выполнить запись
в ячейку снова. Теперь запись пройдет успешно, так как память уже выделена.
5. стр. 272 и еще кое-где. Стандартный перевод для pipe — "конвейер", но уж
никак не "труба".
6. стр 273, первая строка: "всегда доступы процессору". Должно быть "всегда
доступны процессору"
7. стр. 291, второй абзац снизу. "внезапный скачек кривой удельной
скорости". Должно быть "внезапный скачок".
8. стр 302, 2 строка снизу. "SET.ADDRES". Должно быть "SET.ADDRESS".
9. стр. 303. Расщепленные данные обычно называют split, а не splint.
10. Там где ты пишешь про то, что невыровненность данных не так уж влияет на
производительность у меня возникло замечание по поводу многопроцессорных
систем. Не будет ли проблем с атомарностью доступа на многопроцессорных
системах?
11. стр. 38. По поводу низкой разрешающей способности профилировщиков,
основанных на анализе значений счетчиков производительности процессора.
Говорить буду только за VTune. Размытость данных действительно есть. Но
объясняется это не ограниченностью системного таймера, а несколько другими
факторами. Принцип работы Sampling коллектора в VTune следующий. Выбирается
событие, например, Instructions Retired. Процессор программируется на
выработку прерывания после сбора определенного количества Nevents этих
событий. Прерывание обрабатывается драйвером VTune-а, который запоминает
информацию о том, какой пользовательский процесс был активен на момент
выработки прерывания и каково было значение указателя инструкций. Очевидно,
что если выбрать Nevents равным единице, то размытости никакой не будет, но
оверхед будет просто жуткий, и это будет уже не измерение
производительности, а чушь полная. Поэтому выбираются обычно большие
значения N, но здесь начинаются другие проблемы. Связаны они с тем, что
возможна ситуация, когда при N равном, например, 1000 процессор собрал 999
событий в наиболее интересном нам самом горячем месте, а 1000-е произошло
где-то рядом. Тогда все 1000 событий будут записаны на счет именно последней
инструкции, что не очень правильно. То есть важен компромисс. При маленьких
N есть риск исказить ситуацию слишком большими накладными расходами на
обработку прерываний. При больших — статистика по событиям размазывается по
коду (причем размазывается по всем процессам, выполнявшимся во время
профилировки, потому как счетчики производительности — общесистемный
ресурс). Для поиска компромисса в последних версиях VTune есть так
называемая "калибрация". Она представляет из себя холостой запуск сеанса
профилировки, в котором просто подсчитывается количество пойманных событий.
После этого для реального сеанса значение Nevents выставляется так, чтобы,
скажем, в секунду происходило 1000 событий. При этом мы получаем
контролируемую степень накладных расходов и в то же время не завышаем N
больше, чем нужно.
12. Вообще, в книге хотелось бы больше информации по счетчикам
производительности процессоров Intel и AMD. Это такой богатейший ресурс
информации, как можно об этом молчать?
13. Интересно, если есть инструкции PREFETCH для кэша, почему нет чего-то
типа PREFETCHTLB для указания процессору необходимости предзагрузки
информации о трансляции адресов для соответствующей ячейки памяти. Правда,
это уже, наверное, не к тебе вопрос...
14. стр.398-399. Фраза "Во-первых, переписав код на ассемблер, можно на
несколько процентов увеличить его производительность, добившись, по крайней
мере, пятикратного превосходства над штатной функцией memcpy при копировании
небольших блоков". Не совсем понятно. Рисунок показывает обратное —
превосходство есть только при копировании больших блоков, разве не так? И
непонятно, как при улучшении на несколько процентов из 39 процентов может
получиться меньше 20 процентов?
15. стр. 417-418. Здесь, возможно, просто опечатка, но ход рассуждений в
результате проследить трудно:
cs.y = cs.cy;
cs.x = cs.cx;
"Поскольку оба присвоения бессмысленны, то их можно сократить". Как же они
бесмыссленны? Что-то здесь не так...
16. стр. 436. "...основным языком разработки драйверов Microsoft объявляет
именно его, ассемблер, а вовсе не C/C++ или, скажем, Pascal". Неточно. Здесь
надо оговаривать, что драйвера на ассемблере пишутся только в VxD модели для
умирающих Windows 95/98. Драйвера для 98/NT2000/XP уже давно пишутся на
чистом С. Ассемблер применять можно, но совершенно не обязательно.
Достаточно заглянуть в примеры из DDK, чтобы убедиться в этом.
17. стр. 437, первый и второй абзац снизу. "Объективные файлы" — непривычный
термин. Мне кажется, в литературе обычно используется термин "объектный
файл".
18. Во всех, практически во всех примерах в книге нет ни слова какие ключи
оптимизатора использовались при компиляции тестового приложения. Иногда не
совсем очевидно и какой компилятор использовался. В тестировании
компиляторов тоже об этом умалчивается. В общем, такую важную информацию
упускать нельзя. И неплохо хотя бы давать листинги ассемблерного кода,
сгенерированного компилятором. Если нет места в книге, можно это на диске
разместить.
19. И еще. Только без обид. В книге слишком много слов в кавычках. Иногда их
вполне можно опустить без ущерба для смысла. А то меня, например, к половине
книги это немного напрягать начало...
Если все это неубедительно, и это по-прежнему соответствует твоим ожиданиям для "кратко и понятно для начинающих" — замечательно, читайте дальше.
It's kind of fun to do the impossible (Walt Disney)
AS>>>>Я "порекомендовал" не книгу, а ссылку на статью, где описываются вполне банальные приемы профайлинга. Крис там ничего нового не излагает, но и откровенной лажи тоже нет — все вполне приемлемо. Если вы не потрудились ее прочитать — ну, это ваше право. Тем не менее, см. ниже.
AS>>Ну и? Это же не _вся_ книга, а вполне себе отдельный текст. Для новичка — очень кратко и понятно.
AA>Ни фига себе кратко... По поводу статья это или книга — мно по барабану, пусть выдержка из книги. Ты начал утверждать, что это статья, и хотя мне и все равно — не смог удержаться от того, чтобы не подколоть. Мне в твоем первом сообщении твой тон как-то не понравился — отсюда и беседа в неконструктивном ключе.
Ну, тогда действительно все понятно. Конструктива не будет — будут "пальцы".
>> Если есть претензии к указанной статье кроме "книга г-на Касперски это гуано" — тоже интересно. А иначе смысл?
AA>Я как-то раньше уже упоминал подробный список замечаний к данной книге и статье-которая-на-самом-деле-выдержка-из-книги. Это было оформлено в виде письма Крису — ответа от него не последовало. Копирую здесь:
[Skipped] AA>Если все это неубедительно, и это по-прежнему соответствует твоим ожиданиям для "кратко и понятно для начинающих" — замечательно, читайте дальше.
Ок. Из всего списка к указанной статье можно применить только 11 и 18. Являются ли эти замечания хоть сколько важными или конструктивными для рассматриваемой проблемы? Очень сомневаюсь.
А вообще, да, в целом — неубедительно. Как и во всей ветки в ваших сообщениях — смахивает на попытку сказать "какой я умный, а все, включая Криса — отстой". Мое мнение — приведенные вами замечания в большинстве своем являются мелкими _придирками_ (пожалуй, можно принять только 16 и 18 в качестве хоть какого-то конструктива), которых можно накидать к любой книге — взять того же Александреску или Саттера. Наверняка и в том, что порекомендовали вы, при желании можно найти ровно такие же по классу "баги". Повторюсь, в таком ключе это действительно не интересно.
Здравствуйте, Andrew S, Вы писали:
AS>Ну, тогда действительно все понятно. Конструктива не будет — будут "пальцы".
Ну, я не хотел и не собирался, вообще-то.
AS>Ок. Из всего списка к указанной статье можно применить только 11 и 18. Являются ли эти замечания хоть сколько важными или конструктивными для рассматриваемой проблемы? Очень сомневаюсь.
AS>А вообще, да, в целом — неубедительно. Как и во всей ветки в ваших сообщениях — смахивает на попытку сказать "какой я умный, а все, включая Криса — отстой".
Не было такого намерения. Я гораздо глупее многих здесь на форуме, и не питаю иллюзий по этому поводу.
Мое мнение — приведенные вами замечания в большинстве своем являются мелкими _придирками_ (пожалуй, можно принять только 16 и 18 в качестве хоть какого-то конструктива), которых можно накидать к любой книге — взять того же Александреску или Саттера. Наверняка и в том, что порекомендовали вы, при желании можно найти ровно такие же по классу "баги". Повторюсь, в таком ключе это действительно не интересно.
Наверное, я плохо доношу то, что я хочу донести. Эти мелочи очень важны. Хороший программист и писатель *обязан* быть дотошным к деталям и быть в чем-то занудой, если хочешь. Если человек относится недобросовестно к мелочам и допускает в них ляпы — ничего хорошего в "большом" тоже не выйдет. В списке приведены самые очевидные вещи. Их достаточно, чтобы сделать выводы. Еще один вывод, который я для себя сделал — на русском хороших книг практически нет. При всем моем патриотизме.
It's kind of fun to do the impossible (Walt Disney)
Re[11]: профайлинг. нуб квешн
От:
Аноним
Дата:
12.12.07 11:42
Оценка:
Здравствуйте, Alex Alexandrov, Вы писали:
AA> ... Еще один вывод, который я для себя сделал — на русском хороших книг практически нет. При всем моем патриотизме.
А какие есть хорошие книги? Просто единственной книгой, что я читал про оптимизацию, была та самая Криса Касперски.
Посоветуйте, плиз, что-нить стОящее. Ну и желательно в электронном виде
