ну что-ж за примеры ))  а однокласники это тот-же соцэнжин... только соцэнжин убивает сервер при 1000 - 1500 юзверях в онлайне .  У яху много денег, они соберут 500 серверов, наймут инженеров которые будут под фреймворк кластер затачивать, если этого требует задача.  

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

Alexm6, 
Да всё там нормально с фреймворками (не со всеми, конечно, но с большинством). Накладной расход на генерацию не так высок. Время загрузки страницы чаще всего выходит в десятки раз больше её генерации из за пренебрежения клиентской оптимизацией. Переход с apache на nginx/php-fpm даёт приличный прирост в количестве одновременно обслуживаемых клиентов. А введение грамотного кеша вообще списывает все мнимые плюсы работы без фреймворка на нет.

 Пишите на static html - грузить не будет.

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

На основании того, что линейный код будет быстрее работать чем фреймворк. Фреймворк создан чтобы облегчить разработку\понимание системы, за счет производительности.  В нем есть масса кода который нужен только для функциональности ядра или для удобства, это не может не сказываться на производительности. Потери не очень велики при малом количестве запуска кода, ведь не жаль тратить серверные ресурсы ради ускорения разработки в 2 и более раз , но  ситуация меняется если количество запусков кода велико, и даже десятая % разгрузки процессора\памяти, это уже неплохо. 

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



К примеру авторизация, её не впихнуть в кеш, придется работать кодом скриптов при каждом обращении, если при данном телодвижении надо дернуть 50-100кб библиотек фреймворка  ?   или быстрее будет без лишних оберток\классов сделать это ?     
Да, есть акселераторы, которые прекомпилят скрипт. Вопрос в обьме памяти, количестве лишних внутренних вызовов, операций и ифов в конечном исполняемом коде, чем больше, тем медленнее
я кэп очевидность ? )

Alexm6, 
Разработчики дороже железа. Хорошие разработчики много дороже железа.

Изменение кода ядра фреймворка — это самоубийство. Если фреймворк без изменений в ядре нельзя подстроить под себя — это плохой фреймворк.


При использовании APC/XCache не столь критично.


Сделать это будет быстрее с фреймворком. Работать немного быстрее естественно будет лапшекод с формой и её обработчиком в одном файле.

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

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

20% усилий дают 80% результата, остальные 80% усилий — лишь 20% результата

 Линейный код?) Что вы под ним понимаете?
Что мешает использовать фреймворк "линейно"(кроме отсутствия знания фреймворка, конечно же)?

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

Итак, я рассмотрел оба варианта(будет/не будет), в обоих случаях ваш подход проиграл.


 Посчитайте фактически исполненное число строк кода и после этого поймете, что 50-100кб - это бред. Из этого кода выполнится лишь часть. Затраты на парсинг - 0(выш админ не дурак же, чтобы не ставить опкешеры?)

 Его антипод.

 Разработчик стоит допустим 60-100 условных единиц(у.е.).
Допустим за месяц методом спичечных оптимизаций он получит 1-10% прироста.
Допустим сервер стоит 15-30у.е. И он даст 100% прироста.
Считаем и делаем выводы.

Затраты на парсинг не 0, ничего не делается с нулевыми затратами ресурсов
Ваше высказывание очень противоречит логичному :



Говорил о том что этого не будет, о том чтобы не совершать действий которые не нужны для работы


Нормальный сервер стоит 300-500 и более убитых енотов за мес, девелопер дороже, но если серверов в связке несколько десятков накладно выходит, прирост в 10%, даст возможность не ставить лишний сервер, экономим под 5к в год   начальство обычно радуется таким маневрам   ( mchost.ru/dedicated/   сори, не реклама, не самый дешевый, но и не самый дорогой хостинг ). 
ээм, я там делал цитату с пунктом про Васю и его сайты, хост за 15 баксов это для него, а не для нагруженной системы

Alexm6, 

При работе opcode cache они стремятся к нулю.


Естественно медленнее. Тут вопрос не в медленнее-быстрее, а в том, насколько медленнее и существенно ли это.


т.е. вы считаете, что нужно писать всё в 1 файл, совмещая получение и отображение данных?


За 1000$ можно взять очень приличные железки и за 40$/мес., если не меньше, разместить их в нормальном ДЦ.


Нормальный разработчик, который может писать приложения под высокие нагрузки стоит от 1000$ до 3000$ в месяц.
Переписывать проект без фреймворка придётся не менее, чем пару месяцев. Эту пару месяцев заказчик будет терять от 960$ до 2960$ в месяц. Эти деньги можно было бы пустить на покупку серверов, которые увеличат производительность не на 10%, а как минимум на 30—40% (при грамотном проектировании, конечно). В долгосрочной перспективе у нас тоже получится не очень красиво: своего кода без фреймворка больше и его надо документировать. Это дополнительная работа и замедление общего темпа.

 Как это не ноль, если этап парсинга просто пропущен?   

 Ну и не совершайте. С использованием фреймворка.
Вас под дулом пистолета же не заставляют ;)

 Пересчитайте. 10% только от 1 компа(фронтенд). Или у вас зарплата пара сотен?

  
Может быть, но где-то на просторах Сибири?)

nerezus, 
Ну почему сразу на просторах Сибири? Это нормальная нижняя планка, например, для Воронежа. Не все же в пределах МКАД-а 

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

nerezus, 
Это уже оффтоп будет. Но могу сказать точно, что работают.
Могу рассказать почему в ICQ/Jabber/MSN/PM

Лапшу он под этим понимает.
Развернутые циклы, минимум условий и вызовов функций.... все в линию.

Да, памяти скушаем чуток больше (раз эдак в 10ть), но выполняться будет код быстрее примерно на целых!!! 5-15%.

Я с таким столкнулся в 95м у матери. В одном из банков девушка-программист создала отчет на FoxPro.
Порядка пары тысяч строк в таком стиле. В общем... тяжко это все.

Когда потребовалось добавить новое поле.... Пообещали сделать не раньше чем через месяц.
Мать, не зная языка, села и сделала с нуля весь отчет за 3 дня. Уместился он в 5ть строк и форму сделанную в генераторе отчетов.

Alexm6, я, пожалуй, внесу свои 5 копеек. Оптимизация кода - это все, конечно, хорошо. Но здесь уже обоснованно говорили, что для большого проекта( как я понимаю, здесь обсуждаются большие системы корпоративного уровня) очень много из фреймворка тебе придется писать руками. А теперь вопрос - будет ли тебе за это платить заказчик, который покупает твое время и заинтересован в скорейшем появлении результата, так как это часть его бизнеса и часто достаточно существенная? Или он просто пошлет тебя подальше и купит более мощный хостинг? Насколько я знаю, заказчики обычно делают какой-то портал или систему под новый бизнес, который открывают. Следовательно, задержка разработки ведет к задержке ввода на рынок некого нового продукта/услуги, которую предоставляет заказчик, и косвенные убытки от такой задержки могут на порядок превосходить затраты на железо.  

Открою страшную тайну, но без фреймворка - руками писать придётся ещё больше  К тому же не факт, что твой велосипед будет нормальный