Четкость кода уничтожает производительность приложения?

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

Если вы поклонник winamp, возможно, вы захотите прочитать эту замечательную статью о том, как Джастин Франкель провел в AOL интересные времена после того, как AOL купила WinAmp.

Его последний продукт - Reaper .

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

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

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

Specifically with regard to the mp3 player, you're probably not comparing like with like. Your old 486 mp3 player did little but play the mp3, Media Player carries a whole bucketload of cruft doing fancy effects, aero interface and all that stuff. Not to mention it's probably phoning home and a dozen other places on the planet to let Microsoft know what you're listing too :-)

Actually I think this is true more generically, the sort of UI experience we've come to expect today comes at a price both in terms of cpu and memory. I think this will be far more significant than any extra overhead from code structuring (and our compilers a a whole lot more clever too than they were 10 years ago so I even doubt that it is a factor at machine code level)

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

Красивый код может быть быстрым кодом. Проблема может заключаться во многих вещах:

• Языки более высокого уровня значительно сокращают время разработки, но могут стоить процессорного времени. Для большого количества приложений это отличный компромисс.
• Программисты не так хорошо разбираются в алгоритмах, как раньше - это может быть связано с языками высокого уровня, поскольку люди просто используют встроенные в свой язык sort () вместо выбора быстрой сортировки вместо сортировки вставкой
• Приложения теперь делают гораздо больше. Я почти уверен, что Media Player имеет больше возможностей, чем старая версия WinAmp

. Я бы не сказал, что быстрый код мертв. В качестве контрпримеров посмотрите код операционной системы (на ум приходит планировщик O (1) в Linux) и, конечно же, код игры.

Лично я всегда стремлюсь к балансу между производительностью и ремонтопригодностью. Мы давно ушли из тех времен, когда процессорное время было дорогим, а программисты дешевыми, но как пользователь, так и разработчик чертовски неприятно обнаруживать, что одни и те же задачи занимают больше времени в новых версиях того же программного обеспечения, работающих на новых и более быстрых. оборудование ... Итак, субъективно да, я думаю, что некоторые компании зашли слишком далеко в другом направлении.

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

Теперь, если вы используете какую-либо форму генератора кода, это будет зависеть от «качества» исходной выходной мощности генератора. Конечно, в прошлом я видел генераторы кода, которые создавали тонны и тонны мусорного кода для, казалось бы, простых операций. Я думаю, что разработчики инструментов страдали от болезни «все И кухонная раковина». Современные инструменты должны быть более компактными, но стоит проверить инструмент, прежде чем тратить большие деньги.

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

Ура,

In my experience with non-academic software, the biggest performance killer is the use of many layers of abstraction, each of which exacts a modest performance penalty, but they combine like compound interest. Each may be considered a "nice thing" and the "recommended way to do things", until you see the price being paid for it.

You see this especially in event-driven designs, where innocent-looking things like setting a property have a cascade effect throughout a network of classes.

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