Во спасибо Пока ещё не сильно втянулся в django и python повтыкаю сразу оптимизацию
Ранняя оптимизация -- корень очень многих бед Поздняя, кстати, тоже не айс, потому что часто имеет место первоначальная недооценка трудозатрат после профилирования, а по результату оптимизаций\денормализаций становится ясно, что покупка нового\еще одного сервера (или обновление железа у существующего) обошлась бы в ту же цену (в переводе на трудозатраты), но обеспечило бы гораздо более значительный прирост производительности.Есть следствие из второго закона термодинамики, утверждающее, что колебания неустойчивой системы увеличивают ее энтропию.Любая система в процессе разработки (тем более, любая система знаний в процессе изучения) -- система с и без того повышенной энтропией. Зачем ее увеличивать?Кстати, из этого следствия, наверное, можно вывести новое следствие, утверждающее, что система в современном информационном пространстве не может быть актуальной и устойчивой одновременно, т.к. время привидения ее к устойчивому состоянию превышает время появления новой мажорной версии системы... Или же только хардкор и debian-way.Короче говоря, лично мое мнение такое, что заниматься оптимизацией кода есть смысл тогда и только тогда, когда есть 1-5% кода, профилирование которого четко показало, что его оптимизация позволит значительно больше получить в приросте, без потерь в поддерживаемости. С точки зрения стоимости владения системой, рефакторинг в сторону меньшей производительности, но большей очевидности кода, куда выгоднее, чем туева хуча денормализаций ради прироста в 5-10%. И, вообще, оптимизировать стоит только тогда, когда четко известно бутылочное горлышко. С бОльшой долей вероятности можно утверждать, что это будут жесткие диски для мелких проектов, но это может быть и ОЗУ, и процессор и просто возможности масштабируемости системы. И чем крупнее проект или чем больше в нем звеньев архитектуры, тем труднее на этапе проектирования определить это самое бутылочное горлышко. Поэтому нафига козе баян?Питон очарователен своим изяществом, логикой и очевидностью по сравнению с большинством других мейнстрим-ЯП (даже не о таком кэп как perl речь, а о таких уважаемых сообществом языках как cpp, где одну и ту же мысль можно выразить 2^x (где x == количество строк кода) способами, рассчитывая на то, что другой девелопер посещал курсы по ускоренному телепатированию и, естественно, знает, что в твоем проекте используется модернизированная тобой же библиотека Boost). Если, применительно к вебу, забрать у Питона ясность и изящество, то останется PHP, но без батареек. Батарейки -- наживное и временное, а вот красота Python и, с моей точки зрения, некоторая некрасота PHP -- вечны.Два примера из практики (основную мысль уже высказал, так что можно не читать много букв):4 года развивали и поддерживали внутрикорпоративную систему (адская смесь из erp+mes+crm+ecm на moss -- умела всё, и почти всё одинаково плохо) разработанную на .net 2, c фрагментами .net 1.1 (правда местами был 3, а местами 3.5). Приложение сочетало в себе как веб-морду, так и настольные winforms. Очень классная плюшка .net в том, что архитектура позволяет совмещать в приложении код, написанный на разных языках (главное, чтоб был по разным файлам разнесен). Это действительно плюшка, потому что мой сосед писал на vb.net, а я на c#, при этом мне ничего не мешало использовать в своем коде его наработки, а ему в своем -- мои. А третьему соседу, пишущему на С++.net (да хоть на Python for .net или Паскале из BDS) использовать наши классы или интерфейсы к ним в своих объектах. Но это преимущество обернулось редкостной драмой при неправильных акцентах оптимизации, что чуть не привело к сворачиванию проекта.Так вот, когда производительность стала сильно проседать, а особых косяков в коде уже не было (не было того самого 1% кода...), то инициативная группа убедила CIO, что было бы классно переписать отдельные фрагменты кода unmanagement c++ (именно не на С++.net, а на олдскульных страуструповских плюсах исключая прослойку .net; только один компилятор .net позволяет совмещать управляемый и неуправляемый код -- cpp). Dictum factum -- переписали. Получили прирост скорости, поцокали довольно языком и разошлись. А потом каждый новый спринт добавлял новых проблем, потому что неуправляемый код не хотел как надо работать с тем, что писалось на спринте. А откатывать назад было уже поздно, потому что мы философии MS (а MS, выпустив Visual Studio 2000 с первой редакцией .net сказала "проектам" на VS6 (в частности на VCpp6): Бог создал Землю всего за 6 дней, потому что он не поддерживал обратную совместимость). И по нарастающей. Каждый новый спринт пораждает ошибки совместимости с неуправляемым кодом, исправление которых соизмеримо по времени с продолжительностью спринта. Апофеозом драмы был глюк, вызвавший дублирование GUID у сущностей в БД.А потом на роль CIO пришел новый мега-мозг, сертифицированный по MOF (Microsoft Operation Framework -- это что-то очень похожее на ITIL применительно к технологиям MS) и MSF (MS Solution Framework -- что-то типа фрагментарной смеси PMI и Agile, применительно к технологиям MS) и предложил нафиг свернуть проект и нормально внедрить MOSS + Nav + Search Server и т.д... Итого, проект лет на 100-150 трудозатрат чуть-было не закрылся из-за неуместной низкоуровневой оптимизации.Пример №2. В начале нулевых видел код на Делфи, обильно снабженный вставками TASM (а компилятор delphi позволял встраивать ассемблерный код object pascal), но при этом содержащий событие AfterPost (Post -- сохранение записи в БД), которая что-то там обрабатывала, а потом вызывала Post (в то время еще говорили, что рекурсия -- от Бога, все остальное от лукавого ). А так это все было обильно снабжено инструкциями try..except..finally, то все практически зашибенно работало (ну подождать чуть-чуть придется, пока база пошлет нафиг или, что менее вероятно, ОЗУ закончится, а так -- все отлично)P.S. Весь этот поток сознания не относится к некоторым элементарным вещам, типа ленивых запросов и пр. Это относится к большинству фреймворков на большинстве языков. И очень желательно некоторые элементарные вещи знать заранее. Я предполагаю, что мы не рассматриваем откровенный быдлокод, потому что в этом случае вообще нет вопросов к Питону или Джанго. Но вот в остальных случаях (исключая быдлокод), я бы предпочел работать с наивным кодом, чем гиковскими хаками.
