То напишіть на nobuna@meta.ua

Я б сказав що більшість з них використовує і паттерн композиції, і наслідування.

На даний момент форкнув KohanaFramework 3.3.2, додав namespace, PSR-4, Pimple DI, скоротив дещо код... серед іншого залишилась підтримка сесій, автентифікації, баз даних, роутерів (з можливістю зворотньо відтворювати URL)... але не буде тугуватого ORM, поки що не бачу потреби в unitests, minion (різні задачі з командного рядка).

Хоча код мого фреймворка ще дуже сирий, але коли набридає кодити, то міряюсь, так би мовити, з іншими мікро-фреймворками тестами, за допомогою ApacheBench.

Наприклад, такими.
Друкуємо динамічно 100 сторінок, задіявши весь ланцюжок MVC, але просто hello, world!

... 2,35 секунд (42,5 сторінок за секунду).

... 2,018 секунд (49,5 сторінок за секунду).

... 3,285 секунд (30,5 сторінок за секунду).

... 1,535 секунд (65 сторінок за секунду!). Красавчик, правда ж?

... 1,507 секунд (66 сторінок за секунду). Фактично на рівні похибки з CodeIgniter'ом. Прикольно.

Але на моє здивування сама остання версія CodeIgniter (він же такий популярний!) має ще дуже багато не ООП коду. Так на вскидку, то не менше третини він написаний на "функціях"...

Думаю він буде повільніший за всіх тут протестованих, бо він не мікрофреймворк, а повноцінний фреймворк.

Спробував його ради інтереса поставити, але в мене запитало пароль чомусь...

Спробуйте ще:
http://phpixie.com та http://www.slimframework.com/

Але взагалі, я не дуже розумію сенс цих синтетичних тестів. Hello World на свіжому движку з composer - показник нічого. Є два показники, на які потрібно орієнтуватися при виборі фреймворку - а) зручність розробки; б) відповідніть його архітектури до того проекту, який ви будете на ньому розробляти.

Тим більше, що на практиці, швидкість Hello World - це не показник швидкості фреймворку. За моїм досвідом, час, затрачений на запити до баз данних, обробки бізнес-логіки вашого сайту та всього такого іншого досить суттєво перевищує той, який витрачається на простий hello world. Це дуже дивує деяких людей, але на практиці навіть досить повільна Symfony на реальних проектах не настільки програє тому ж CodeIgniter, як можна було б сказати з hello world тестів. Окремо по швидкості стоїть Phalcon, але й там не так все райдужно. наприклад, відсутніть у його ОРМ можливості eager loading може зробити його роботу над пов'язаними об'єктами повільнішою, аніж у того ж Symfony з його монструозною Doctrine.

А якщо хочеться справжньої швидкості -
http://www.techempower.com/benchmarks/#section=data-r9 ці тести дуже добре демонструюсть, що PHP у цьому випадку - далеко не найкращий вибір.

Жесть!

Тобто видає 100 сторінок за 0,876 секунд (114 сторінок за секунду). Як таке можливо!!?

Навіть ApacheBench каже:

P.S. Щось slimframework не заходів просто заводитись... не було часу розбиратись чому. Мені значно цікавіше покопатись в phpixie як там все зроблено, тим більше він теж виявляється є форком KohanaFramework. =)

Дякую, TwiStar. Чого ж ви раніше тут не відписувались за нього?
PHPixie дійсно дуже раціональний і добре написаний OOP MVC мікрофреймворк. Для простих проектів підійде дуже добре. Новачкам рекомендую для вивчення.

Вже зараз у нього є підтримка самих часто вживаних модулів.

При бажанні, його можна вивчити за пару днів, особливо якщо використовувати XDebug + IDE.

Стосовно масштабованості, то я поки що не побачив у ньому можливості перевизначення класа, якщо потрібно, щоб таке перевизначення впливало надалі на весь існуючий ланцюжок наслідувань. Тобто не горизонтальне розширення, а вертикальне наслідування.

Наприклад, якщо певний клас має 5 дочірніх класів, то при потребі перевизначити другий клас в ланцюжку, не вийде це зробити, бо в коді жорстко прописані "системні класи". В такому разі прийдеться переписувати цілу гілку класів...

Але з іншої сторони цей фреймворк на стільки легкий, що я в ньому ще не побачив ланцюжка з 5 наслідувань...

Я теж не уявляю як ви уявляєте збільшення масштабу проекта без необхідності перевизначення раніше написаних ланцюжків наслідувань...

Мікрофреймворками я цікавлюсь, в першу чергу, через потребу досконало знати кращі практики, де поєднуються швидкість з MVC ООП + гнучкість налаштувань.

Тут потрібно пояснити, що ви маєте на увазі, говорячи про масштаб проекту? Більше навантаження чи розширення функціоналу? Перший випадок не має жодного відношення до наслідування. У другому випадку потрібно дотримуватися принципів SOLID та взагалі використовувати композицію над наслідуванням там, де це можливо. Ланцюжок з п'яти наслідувань рідко коли має право на існування, і той випадок де потрібно замінити один з предків - явно не той.

Тут потрібно сказати, що кращі практики ООП дуже заважають швидкості. Наприклад, ОРМ - дуже зручна, практична та добра річ, але її використання - це кошмар з точки зору швидкості. Чим складніша архітектура - тим більше ресурсів використовується при її ініціалізації. Але у той же час не варто думати, що можна розв'язувати складні задачі, не ускладнюючи структури коду. Це підтвердить будь-хто, кому довелося підтримувати сайти, де архітектурою та добрими практиками нехтували.

Я в 10 з 10 випадків виберу швидкість розробки, легкість заміни компонентів та зручність у виправленні помилок міллісекундам при відображенні сторінки. Це не змагання зі швидкості. Якщо система перестає працювати достатньо швидко, її можна оптимізувати - і це буде досить просто, бо це є однією із основних властивостей гарної архітектури - компоненти в нії не залежать один від одного, і можна замінити один компонент іншим, без необхідності переписувати значні частини системи. Але при тому, така архітектура сама по собі буде набагато повільніша за "простий" код. А простиня, де весь код зашитий в index.php взагалі обійде будь-який фреймворк на всіх тестах як стоячого.

Всі хочуть. Срібної кулі немає. Мені подобається Laravel, але його не можна назвати еталоном швидкості та стабільності api.  Silex (молодший брат Symfony) досить швидкий, зі стабільним api, модульний донеможна, але як і у старшого брата Pull Request-и там можуть приймати місяцями, якщо баг не є критичним.
Взагалі, багато фреймворків почали рухатись у напрямку створення незалежних компонентів, які можна використовувати окремо від фреймворку - і тут є величезний простір для експериментів. Тобто, можна взяти Slim, підключити йому Eloquent від Laravel як ORM, Twig для відображення, модуль аутентифікації від Aura, і так далі - і все це буде спокійно собі працювати. А можна взагалі зібрати свій фреймворк лише з готових компонентів - усілякі роутери, орм, DI контейнери, шаблонізатори давно написані та чекають свого часу (мені досить подобаються компоненти тут - https://github.com/orno).

P. S.

Ставив фреймворк через composer - і ось код Hello World.

<?php

require "vendor/autoload.php";

$app = new Slim\Slim;

$app->get('/', function () {
    echo "Hello World";
});

$app->run();