Прочитал главу из книжки. По совету Jeff Atwood-а. Книжка старая но она не из серии "С++ за 24 часа" и не устареет никогда. Глава посвящана простой идее что самый лучший оптимизатор находится между ушей того кто дизайнит программу. И какой бы навороченный компилятор он не использовал и на каком бы низкоуровневом языке не писалась программа плохой дизайн не исправишь ничем. Заявление сопровождается примерами вычисления check суммы файла. В книжке много примеров которые на моей машине исполнялись от пол-минуты до очень малых долей секунд при том же входном файле. Шаг за шагом автор объясняет как можно улучшить результат предидущего примера. Верхом оптимизации становиться лучший алгоритм написанный на ассемблере но он лучше всего на доли секунд аналогичного на С и издержки программирования на ассемблере могут быть больше чем преимущества алгоритма, хотя - кто знает? Если надо обработать миллионы файлов то доли секунд станут минутами и это уже может иметь влияние на восприятие программы. Еще одно наблюдение что надо очень хорошо знать платформу и язык на котором работаешь. Причем на лучше всего на самом низком уровне. Я например не знал что чтение байта из файла с помощью read() и getc() совершенно разные. read() читает байт с диска на каждое обращение а getc() кэширует кусок файла в своем буффере и последующее чтение идет из него. Таким образом улучшая производительность. Не зная этих деталей никакой толковой оптимизации не добъешься. Поэтому даже программируя в управляемой среде как Java или .NET надо знать что делает платформа на нижнем уровне, какой API использует.
No comments:
Post a Comment