Friday, March 14, 2008

Виста сакс

vistlipse В продолжение моего поста про Висту. Я работал под ней уже несколько месяцев и не доволен. Виста нестабильная. Программы падают и очень часто. При этом это программы написанные Майкрософтом и что еще хуже - под Висту. Программы написанные ранее тоже часто не работают. Например мой Microsoft Money 2007 не работает под ней.

Один раз удалив zip  архив Виста вместе с ним удалила весь фолдер в котором он был. В фолдере был результат двухдневной работы и восстановить было никак. Хорошо у меня была запасная копия на USB брелке.

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

Я люблю когда программы работают быстро. Мне не столь важно чтобы они красиво выглядели сколько как бысторо они работают. Деньги = Время, верно? Я не могу хочу сносить Висту и ставить ХР потому что Майкрософт делает некоторые технологии только на Висте или они только на ней имеют смысл и мне с ними надо работать WPF например. Но остальным для повседневного пользования я бы советовал остаться с ХР как можно дольше. Я надеюсь что Виста разделит судьбу Windows ME и будет заменена чем-то более уместным иначе придется пересесть на Линукс.

Самый лучший оптимизатор

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