Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
PD>Теоретически — совершенно безупречное рассуждение. А практически — это
PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!

А как вам вот такой тезис, что программа просто должна быть достаточно xxx?
Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать; если проект после 1.0 не планируется отправить в архив то достаточно сопровождаема; и т.д. А скорость эскадры равна скорости самого медленного корабля.

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

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