Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>С этими проблемами потом пользователи его продукта сталкиваются . Ежедневно, ежечасно, и в массовом масштабе.
AVK>Опять же по опыту скажу — нарекания на производительность от заказчиков явление редкое.
Может быть, у меня была уникальная работа, но от меня в первую очередь требовали производительности. Скажу больше — ради этого меня в команду и приняли. Проект уже несколько лет как был в работе, их многое не устраивало, но от меня требовали только одно — обеспечить доступ к данным с максимальной скоростью. Потому что если образец не будет обработан за 3 сек — его безжалостный тайм-шедулер просто сбросит.
Это во-первых. А во-вторых — а не кажется ли тебе, что заказчика мы сами воспитываем так, что он принимает низкое быстродействие как должное ? Почем ему знать, что здесь можно выжать, он же не специалист! Тебе автомобиль дали (допустим, ты не спец в них), он 120 выжимает, других нет — хорошо. А то, что он мог бы 160 выжимать — ты и не узнаешь. А компьютер и ПО ИМХО посложнее. Тем более что апгрейд автомобиля ему не посоветуешь, а тут все ясно — купите еще памяти, второй (третий и т.д) процессор, кластеризацию устройте и т.д. А он этому верит — специалист же советует, и хороший (без иронии говорю).
>Куда больше притензий по юзабилити, недостаточному функционалу и глюкам.
Юзабилити и недостаточный функционал — за пределами этой дискуссии, это отдельная тема. Глюки — да. Но убедительного доказательства, что расточительно написанная программа будет более безошибочной я не вижу.
Еще раз, да поймет меня тот, кто слышит (это не лично к тебе). Я не против хорошего проектирования , дизайна и т.д.
Я против бесконтрольного использования заведомо неэффективных решений под видом лучшего проектирования и т.д. Я против расточительных конструкций — независимо от того, кто их делает — программист или библиотека.
>Производительность, как это не парадоксально, почему то больше всего заботит программистов.
Эх, если бы. Боюсь, грядет век, когда она их и впрямь заботить не будет. Будут плодить монстров, жрущих память и ресурсы, медленные как черепахи , зато понятные и легко сопрвождаемые, да еще и говорить, что это, мол, главное. Как будто программы делаются не для того, чтобы они работали лучше, а для того, чтобы их модифицировать было легче.
Вообще мое настроение на этот счет назвать оптимистическим нельзя.
AVK>И даже если притензии по производительности есть, то они практически всегда определяются скоростью БД или внешних устройств, так что игры с битами и ручным управлением памятью в таких случаях ничем не помогут.
Где как. К примеру, в моем проекте заказчик вынужден был отказаться от баз данных и мне как раз поручили написать свою систему хранения информации в файле. Я удивился и спросил — почему БД не использовать ? Ответ был прост — недостаточно быстро. Надо сказать, что БД в этом проекте была константой, т.е в нее изменения не вносились вообще, она раз в 3 месяца перегенерировалась и всем рассылались новые копии. Я не поленился, запросил в ФИДО конференции по БД (RSDN тогда еще не было), от какой БД можно ждать получения данных в таком-то и таком случае за 50-70 мсек ? Меня там на смех подняли
. Я и сыграл на константности данных — только поиск. А в итоге я сделал доступ в 90% случаев за 20 мсек или менее при том , что поиск практически всегда шел с wildcard, т.е. типа LIKE. На это я много времени убил
Да, здесь можно было от БД отказаться. В других случаях нельзя. И то, что при условии, что БД лимитирует, оптимизировать нет смысла — понимаю и не против. Кстати, как химик с понятием лимитирующая стадия процесса знаком не понаслышке
. И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
Ну а внешние устройства — тема особая.