jeje 5 авг 2009 в 13:39

Хранение кода в бд или собираем код по кирпичикам

7 мин

11K

Веб-разработка *

+18

270

Комментарии 270

AxisPod 5 авг 2009 в 13:47

Зачем хранить в бд то, что лучше хранить в файлах? Уже давно использую магический метод __call для решения данной задачи, все методы хранятся в отдельных файлах, при условии что код можно перед использованием копироваться в рамдрайв, что существенно повысит скорость обращения к файлам, да и редактировать код при хранении в файлах в разы проще. А хранение кода в БД чревато тем, что невозможно использовать различные компиляторы и кэшеры исполняемого кода, а include в свою очередь быстрее отработает чем eval и закэшируется исполняемый код.

Napolsky 5 авг 2009 в 13:58

>>Зачем хранить в бд то, что лучше хранить в файлах?
для этого в статье отведен пункт «плюсы» )

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

>>include в свою очередь быстрее отработает чем eval
Совсем необязательно использовать eval. Codegen вполне может собрать такой код, который не будет нуждаться в загрузке кода «на лету» из бд.

scorcher 5 авг 2009 в 15:13

Плюсы конечно тут хороши. Слов нет.

Но есть ряд минусов, которые опущены в статье:
1. огрмный размер кеша (если конечно это не домашная страничка какого-нить мальчика из неизвестной деревни.)
2. как уникально генерить ключ для кеша? хорошо если проект маленьки, а если большой и активноразвивающийся.
3. вообще если из вашей идеи убрать БД — уже будет лучше.
4. дебаг усложняется при использовании __call, а при использовании еще и БД, вообще бэктрейсы будут веселые.

вот пример одного крупного проекта:
Кол-во файлов движка — ~4089
Кол-во строк в этих файлах — 652091
В среднем по 160 строк на файл.
Вес: 43 метра
Нагрузка — так, небольшой highload. (~150qps)

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

Заигрались с идеями, ИМХО…

А за нестандартное мышление только респект! Направление верное, но надо шкурить…

scorcher 5 авг 2009 в 15:16

ААА… и еще забыл.
нужен же еще и какой-то маленький файл starter.php, который будет исходя из REQUEST_URI, POST, GET и прочего составлять ключ для кеша и в случае отсутсвия кеша — бежать генерить… и это должен быть какой-то отдельный скрипт от движка.

Napolsky 5 авг 2009 в 15:23

Извините, но я совершенно не понял про кеш — что тут с кешем такого страшного должно случиться при таком подходе?

scorcher 5 авг 2009 в 15:31

вы пробовали оценить сколько у вас вариаций загрузки различного кода?
например, хотя бы, в зависимости от REQUEST_URI

egorinsk 6 авг 2009 в 20:31

Извините за дурацкий вопос, но как вы умудрились написать 43 Мб кода??? Куда столько? У меня есть серьезные подозрения что большая часть такого кода — сплошной копипастинг (например, модули, у которых 80% кода одинаково).

Fortop 7 авг 2009 в 05:44

Да ну? :) у меня есть серьезные подозрения что в этом коде включены как минимум какой-нибудь фреймворк и ОРМ.

Тем не менее, проект на 3-5мб кода я вполне себе представляю :) без всякого копипастинга :)

scorcher 7 авг 2009 в 13:07

этот код писала команда программистов в течение 4-5 лет.
Что тут удивительного?
Некоторые алгоритмы повторяются из библиотеки в библиотеку, из модуля в модуль, но только с целью ускорения кода… Система постоянно развивается. Ее не возможно было спланировать всю целиком. Не исключаю, что 10-20% этого кода уже отмер (тоесть не используется по факту, но он рабочий).

Кстати мы когда то тоже задались этой проблемой, что для отображения списка скажем вот такой же странички как эта от модуля необходимо лишь получить статью, и комментарии.
Но кроме этого в модуле были еще и другие состояния и блоки… и они постоянно грузились…
Было предпринято наипростейшее решение — сделать все состояния, обработчики и просто методы в модуле через magiс метод __call(). Размер загружаемого кода резко сократился…

Fortop 7 авг 2009 в 17:27

Хм, я негативно отношусь к magic методам.
В свое время экспериментировал с самонастраивающимися классами для данных.

Да, удобно, но при этом реально медленнее раз 10-30.

scorcher 7 авг 2009 в 18:08

Интересно посмотреть на замер…
какая разница в нагрузке на CPU при интерпретации файла 150-200Кб и двух-трех файлов размером ~5Кб? Замеряли?

Fortop 7 авг 2009 в 21:51

Нет нагрузку CPU не мерял.

Мерял лишь время выборки из БД и заполнения коллекций.
Даже не столько мерял, сколько столкнулся с этим уже в работе :)

Если в коллекции используются конкретные модели с заранее указанной структурой,
class box {
public $a;
…
public $z;
}

то время порядка 0.5-0.7с всего лишь для нескольких тысяч объектов.

А вот когда использовалась «универсальная» модель, которая строила себя по метаданным таблицы, а затем предоставляла доступ через magic методы к своим полям и методам,

class unibox {
public function __get() {}
public function __set() {}
public function __call() {}
}

то система задумывалась на 5-15с над теми же данными.

Уточнение в моделях было порядка 10-30 полей данных.

Получение служебной информации по таблице всего лишь +1 несложный запрос.
Таким образом magic-методы вызывались порядка 30-200т раз и именно это вызывало замедление работы скрипта с 0.5с до 15с

P.S. цифры несколько неточны, писал по памяти, но порядок такой.

scorcher 8 авг 2009 в 05:33

мы немного о разном…
мы код прячем за _call метод и вызываем — один раз.
а вы кучу данных и обращения к ним за методы __get __set и вызывает много раз.

Fortop 8 авг 2009 в 08:38

Мы все об одном и том же.
Когдо magic метод вызывается 1-2 раза — все отлично. А вот если оно вызывается много раз…

При частом использовании __call вы таки вызовете с его помощью какой-нибудь метод где-нибудь в цикле. И вот гложут меня смутные подозрения (потому как не проверял), что __call не быстрее __get/__set и у вас будут те же грабли :)

scorcher 8 авг 2009 в 18:31

аа… ну дак именно по этой причине за __call вынесенны ТОЛЬКО состояния и обработчики, которые занимают основную часть сложного модуля. (я об этом писал)
А часто используемые методы написаны прям в классе.
Тут я с вами полностью согласен.

MgDuke 6 авг 2009 в 11:50

Так как уж Вы процитировали меня в своём топике, выскажусь.

«Мёртвый код»? Сударь, ваши PHP скрипты уже хостятся в огромной матрёшке «мёртвого кода» ( ОС -> Вебсервер -> PHP интерпритатор -> СУБД ) из «возможностей» которых используеться 2-3%. Может тогда резонно свою ОС написать, под сайт?

Я не могу сейчас точно сказать как решена проблема ускорения парсинга PHP, просто потому, что им не занимаюсь, но на 99% уверен, что продукты Zend'а решают эту проблему, прогоните код через оптимизатор и сравните результаты. Что касается .NET и Java описанная вами «проблема» для них вообще не актуальна.

Увеличение быстродействия — очень спорный момент, без тестов ничего не говорит.
Все ваши плюсы можно без мазохизма имплементировать классическим ООП.

Скину ка я сюда полную версию минусов с прошлого поста:

— IDE работают с файлами
— исходники это файлы, в итоге с ними можно делать любые файловые операции
— поддержка, наверняка человек пришедший после вас на такой проект сочтёт вас идиотом
— производительность, в большинстве случаев скрипты \ рантаймы могут применять какие-либо оптимизации, включая кеш, а ваши BLOB'ы уж никак сюда не впишуться
— Распостранение, ох некрасиво таскать SQL дампы туда — сюда
— Безопасность, прямой код инжекшн в случае проблем
— Бекап, представляете, бывает так, что их не делают, и тогда любые ваши «кастомизации» on site коту под хвост если сломаеться база
— Отладка отвратительна
— Нормальная поддержка ОПП, — не возможна
— Очень вероятны скрытые дефекты при работе с shared statеом
— Eval ВСЕГДА дефакто будет медленее обычного выполнения
— Версии \ бранчи \ мерджи \ итерации не возможны
— Runtime migration, при переходе на новый рантайм ошибки совместимости не будут выловлены вовремя

TedBeer 7 авг 2009 в 18:49

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

Fortop 7 авг 2009 в 22:00

Она не будет надежна на все 100.
И разработчики будут допускать ошибки, а тестировщики будут их пропускать.

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

P.S. попробуйте для развлечения подебажить запакованый javascript получите огромный оргазм…
если вам таки удастся продебажить или вам все же дадут в итоге незапакованную версию кода :)

TedBeer 8 авг 2009 в 09:55

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

Fortop 8 авг 2009 в 16:24

Хм, а я разве несоглашался?

Я указал вам на те подводные камни с которыми вы столкнетесь. И, несмотря на то, что я могу дебажить по дампу, удовольствия от этого мало. Хотя, конечно, дело привычки, можно и бинарный код, и packed javascript научится читать как обычный листинг.

P.S. и, да, я предпочитаю в продакшене незапакованый код, если это не касается тех частей которые можно быстро и безболезненно подменить отдельно от всей системы (как обычно и бывает, к примеру, с javascript).

beetleinweb 6 авг 2009 в 07:49

Может быть автор немного опередил своё время? :) На самом деле, нет таких вещей, которые лучше хранить в файлах, чем в базах данных (особенно заточенных под характер данных). Файловая система — это «недобаза данных». Чрезвычайно быстрая лишь в силу своей упрощённости.

Ну и вспомним WinFS, почившую в бозе, но вроде бы имеющую шансы на возрождение. Налицо тенденция превращения файловых систем в практически полноценные базы данных.

Возможно, не следовало сразу вываливать на неподготовленные головы две «технологии» одновременно — «кирпичики» и «код в БД». Хранение кирпичиков в файлах, даже вместе с атрибутами (в комментах или индексных файлах) было вполне возможно.

Napolsky 6 авг 2009 в 09:36

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

Joka 5 авг 2009 в 13:50

есть несколько вопросов

а как написать блочные, нагрузочные, модульные и другие тесты при таком подходе? доставать код прямо из базы данных?

профилировали ли вы из-за чего произошло уменьшение генерации кода — потому что стало меньше невыполняемого кода? а мне лично всегда казалось что одним из узких мест является именно база данных. хотелось бы увидеть данные профилирования

Joka 5 авг 2009 в 13:53

еще вопрос — как себя ведет эта концепция при высоких нагрузках? не загинается ли база данных от запросов по доставанию кода который потом еще сделает сколько то там запросов к ней?

Napolsky 5 авг 2009 в 14:04

Уменьшение строк кода на страницу происходит из за того, что мы полностью исключаем из нее код, который заведомо не может быть выполнен.
База данных не является здесь узким местом. Я выделил жирным в статье, и еще раз повторю, что при загрузке страницы пользователем, мы можем вообще не обращаться к нашей бд. Мы обращаемся к ней лишь 1 раз, когда генерируем новые коды страниц (например при изменении кода какого то модуля или еще чего либо)

Joka 5 авг 2009 в 14:06

понял, мне кажется таким подходом вы просто создаете себе дополнительные проблемы при тестировании кода

Grundiss 6 авг 2009 в 07:30

Рискую сейчас сказать глупость, но разве PHP не использует т. н. «ленивые вычисления» (http://ru.wikipedia.org/wiki/Ленивые_вычисления). И если использует, то не наплевать ли PHP на «мертвый» код?

mx2000 6 авг 2009 в 08:22

Синтаксический разбор исходного кода происходит в любом случае, независимо от востребованности того или иного куска кода. А «ленивость вычислений» — это немножко другое ;-)

Grundiss 6 авг 2009 в 08:41

А, вот о чем речь! Видимо неправильно понял суть статьи. Ну, экономить на синтаксическом разборе = экономить на спичках ИМХО. Кроме того разбор все равно будет: надо ведь разобрать кодеген, а затем разобрать чего он там нагенерил. Так что будет ли ощутимый плюс во времени — большой вопрос. Кроме того запрос в базу тоже выполняется некоторое время.

NickMitin 5 авг 2009 в 13:54

а чем плох __autoload?

Assargin 5 авг 2009 в 14:42

Очень хорош, кстати, если пишем на классах.

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

Плюсы:
1) Автолоад в дальнейшем в самом простейшем случае состоять может из одной строки «require(имя_класса.class.php)». По-хорошему, конечно, нужна и проверка ентого файла на существование перед подключением
2) внутри classes я могу создать какую угодно структуру каталогов, если этого не надо, то и подкаталоги сканить не надо ))

Минусы:
1) каждый раз рекурсивно сканить каталог. Ну если напрягает такое положение дел, получившуюся строку path можно закэшировать, на продакшне — чуть ли не навсегда))
2) не знаю.

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

У баз, конечно, есть килограммы преимуществ перед обычной файловой структурой. Но в этом ли случае их использовать, автор статьи?)))

aubt 5 авг 2009 в 14:45

По-хорошему, конечно, нужна и проверка ентого файла на существование перед подключением

а, собственно, зачем? такая проверка есть внутри require, который, в случае чего, выкинет fatal error и на этом выполнение программы закончится.

Assargin 5 авг 2009 в 14:51

ну вот поэтому она и нужна, эта проверка )) чтобы никаких фатал ерроров пользователи не видели, незачем им это))

Да и вообще, в продакшне проверка файла подключаемого класса на существование — из разряда «проверить что 3=3» — ясен пень, что ну куда ж файл то денется?))

aubt 5 авг 2009 в 14:53

чтобы никаких фатал ерроров пользователи не видели

set_error_handler прекрасно справляется с этой задачей. двойные проверки плодить незачем, по-моему.

den1n 6 авг 2009 в 11:46

Т.к. require генерит E_FATAL при отсутствии файла, то у Вас не получится отловить ошибку с помощью set_error_handler. «The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.» © www.php.net

aubt 6 авг 2009 в 16:19

Выполните у себя код:

<?php

function errorHandler($no, $str, $file, $line)
{
	die("gotcha!");
}

set_error_handler("errorHandler");

require "no_such_file.php";

?>

den1n 6 авг 2009 в 17:31

Эх, ошибся. Извините.

aubt 6 авг 2009 в 17:36

Вас не за что извинять, судя по всему ошибка в документации (судя по ней, приведенный код работать не должен).

Вы ошиблись только в типе ошибки require — он выкидывает E_ERROR.

aubt 5 авг 2009 в 14:54

Да и вообще, в продакшне проверка файла подключаемого класса на существование — из разряда «проверить что 3=3» — ясен пень, что ну куда ж файл то денется?))

именно! :) поэтому и незачем при каждом исполнении кода проверять есть ли файл по два раза.

standov 5 авг 2009 в 15:48

ну вообще обычно делается 2 режима (константа) DEV|PROD вот в деве все возможны проверки в основном для понимания ошибки разработчиком в PROD по минимуму — несколько увеличивается скорость
принцип такой, если в DEV у разработчка работает то и в PROD должно но в PROD все сообщения об ошибках отключаются полубому (ведь правда? ;))

NickMitin 5 авг 2009 в 14:51

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

magicstream 5 авг 2009 в 19:36

ого!!!.. по моему вы не используете настоящие преимущества __autoload

Assargin 6 авг 2009 в 04:21

какие, например?)

TWINc 6 авг 2009 в 07:18

Например один раз сканить папку с классами и кешировать результат. В __autoload банально проверять запись по ключу(имя класса) и делать require.

ps. require вне __autoload делать не нужно. зачем тогда собственно нужен этот _autoload?

magicstream 6 авг 2009 в 07:50

«При начале работы скрипта в переменную окружения path ini_set'ом загоняем classes и все ее подпапки.»
— лишняя нагрузка на сервер

«Автолоад в дальнейшем в самом простейшем случае состоять может из одной строки «require(имя_класса.class.php)».»
— а как на счет коллизий?
это произойдет когда встречаются два файла с одинаковыми именами и но эти файлы находятся в разных каталогах.
вам придется следить за уникальностью имен всех файлов.

не вижу смысла запускать рекурсию по каталогам и добавлять все найденные пути в include_path когда само имя класса говорит где искать.
пример: calss DB_Table_Row — лежит в фале DB/Table/Row.class.php
при $row = DB_Table_Row(); — autoload-у не составит труда найти класс

Assargin 6 авг 2009 в 09:49

«Лишняя нагрузка» при сканировании структуры каталогов может быть по сути один раз, потом результат на продакшне кэшируется, хоть навсегда. Я писал это в комменте выше.

какие коллизии в именовании файлов?? Файлы именуются, например, имя_класса.class.php. Значит, имена классов одинаковые?? А чтобы не было коллизий с другими файлами, которые не в classes, надо файлам классов давать префикс/суффикс

— лежит в файле DB/Table/Row.class.php

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

Fortop 6 авг 2009 в 11:32

Хм, а это не извращение. Это нормальная организация для проекта где больше 2-3х классов.

Когда у меня одних структур три десятка, да моделей штук 8, да драйвера к разным устройствам вывода…

Держать все в одной папке? Увольте.

Assargin 6 авг 2009 в 12:22

То, что Вы видите, называется дерево комментариев. И в ней разворачивается беседа. Ознакомились ли Вы с ней? Я бы сказал, что нет.

— Держать все в одной папке?
как я писал выше (http://habrahabr.ru/blogs/webdev/66309/#comment_1863308)
> 2) внутри classes я могу создать какую угодно структуру каталогов,
>если этого не надо, то и подкаталоги сканить не надо ))

Но и заниматься чем-то вроде DB/Table/Row/Field/ — не понимаю зачем. Или если есть возможность, то надо истерично заюзать ее? )) Вполне хватить может 2-3х уровней, ИМХО. Но не в одной папке))

Fortop 6 авг 2009 в 13:01

То что вы пишите называется «смотрю в книгу вижу...»

Вот смотрите:

DB/Table/Abstract.php
DB/Table/Mysql.php
DB/Table/Postgresql.php

Feed/Abstract.php
Feed/RSS.php
Feed/Atom.php

Причем, заметьте подкаталоги сканить не надо вообще. Имя класса фактически путь к нему.

Предложите свою структуру для хранения внутри вашего «classes», и рассмотрим преимущества и недостатки в сравнении с этим «извращенным», как вы выразились, методом.

DeFacto 6 авг 2009 в 15:29

вроде в Zend Framework так реализовано?

IDMan 6 авг 2009 в 17:11

так точно.

egorinsk 6 авг 2009 в 13:34

Autoload —фигня. Он провоцирует на использование невменяемых названий типа Zend_DB_Table_Abstract_Class — ну не бред ли? Руки же отвалятся писать.

Кроме того, создавать объекты через new не всегда правильно, например объкт подключения к БД должен быть один, или там модель можно ичпользовать повторно а не создавать заново.

Поэтому в хорошем фреймворке должен быть объект, генерирующий (или достающий из кеша, или еще откуда-нибудь) то, что его попросят. Простейший пример такого объекта есть в codeIgniter — $this->load->model('name'). такой поход во-первых не заставляет нас писать невменяемые имена классов, во-вторых не связывает местоположения файла класса с структурой файлов, в-третьих позволяет кешировать/переиспользовать ранее созданные объекты.

Все остальные решения имхо — фигня с кучей недостатков.

david_mz 6 авг 2009 в 20:27

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

2. Кто мешает использовать синглтоны? Абсолютно никто не мешает…

3. Один из возможных подходов. Но не единственный.

4. Категоричные суждения редко бывают истиными:)

egorinsk 6 авг 2009 в 22:20

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

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

> 2. Кто мешает использовать синглтоны? Абсолютно никто не мешает…

А в чем смысл раскидывать кучу синглтонов и писать мудреный autoload-код, если можно все это собрать в 1 специально предназначенном объекте? А когда кеширование сериализованных объектов (к примеру) будете добавлять, тоже всюду проходиться?

Ну не знаю в общем.

Fortop 7 авг 2009 в 05:51

А вот для того чтобы руки не отваливались используйте «нормальные» адекватные IDE с кошерным автокомплитом :)
И читать такое несколько удобнее, чем именя а-ля pcntl_wtermsig()

P.S. В редакторах типа vim тоже обычно бывыет автокомплит. Вот только он некошерный :) Потому что не контекстный.
Он автоматически не подтянет методы касающиеся только контекста.

Becoming_Insane 8 дек 2009 в 10:04

$this->load->model('name')

а что с подсветкой будет?

egorinsk 8 дек 2009 в 15:38

С автодополнением? У меня его все равно нет, мне по барабану :) Но по моему ради автодополнения менять архитектуру — это немного… того… странно.

iBear 5 авг 2009 в 14:09

Вы предлагаете кэшировать код вместо результатов?.. Ну я даже не знаю что вам на это сказать…

А от повторения кода избавляет как минимум использование функций (вроде checkAdmin() написать не сложнее _CHECKADMIN), да и вообще современные парадигмы проектирования приложений решают эту проблему.

P.S. Попадись мне приложение куски кода которого лежат в базе — я бы поседел.

Napolsky 5 авг 2009 в 14:18

Я ни в коем разе не предлагаю кешировать код вместо результатов.Где вы про это прочитали? )
_CHECKADMIN был просто приведен для примера, чтобы можно было уловить суть обработки кода перед исполнением.
Знаете, попадись мне приложение с кодом в базе года три назад, я бы тоже наверное поседел =)

leshaogonkov 5 авг 2009 в 14:12

А какой хостинг вы используете? На виртуалке обычно работа (нстройка) с БД сильно урезана. В том плане что рассчитана БД на какие-то более-менее типовые задачи.

Насколько ваш метод требователен к настройкам БД?

Napolsky 5 авг 2009 в 14:23

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

nuzni 5 авг 2009 в 14:16

Началось, лучще хуже.
Статья очень сильно заставляет задуматься и убедиться что:
1. Альтернатива есть всегда.
2. Умение смотреть под разным углом — это плюс программисту.
3. Всегда есть место открытиям новшествам и улучшениям.
4. Месье знает толк в извращениях.

НЛО прилетело и опубликовало эту надпись здесь

aubt 5 авг 2009 в 14:31

Заголовок, думается мне не совсем верный. Причем тут, собственно, БД вообще?
На входе имеем «классический» код, который преобразуется в «кирпичики» в базе, из которых «собирается» сугубо исполняемый код для каждой страницы. Ну использована была БД в этом процессе, ну и что? :) На продакшен можно выкладывать уже «собранный» код, как я понимаю?

И опять же, не понятна ремарка насчет средств разработки. Зачем Вам средства разработки на продакшене? Пишите все в любимой IDE, перегоняйте в кирпичи, потом через Codegen в собранный код, и назовите этот процесс «компиляцией» :) Причем, выделенное курсивом, вообще говоря, может (и должна) делать одна программа.

Либо я что-то не так понял.

aubt 5 авг 2009 в 14:34

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

Napolsky 5 авг 2009 в 14:47

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

chetzof 5 авг 2009 в 15:49

«Но на прочтении и парсинге кода тоже получается экономия „

А вы не забыли использовать echo вместо print и ординарные кавычки вместо двойных? Тоже ведь экономия… правда на спичках :)

Fally 6 авг 2009 в 12:14

Извините меня конечно, но если экономия на парсинге кода, это экономия на спичках, то зачем для PHP есть 3(!) кэшера байт-кода… Вам это странным и противоречащим вашим словам не кажется? + Всё зависит от файлов, иногда приходиться инклудить очень большие сгенерированные таблицы с данными, для оптимизации во время выполнения…

Napolsky 5 авг 2009 в 14:42

немного не так. Мы имели «классический» код и преобразовывали его в «кирпичики» только один раз — когда осуществляли переход от «классической» архитектуры. Сейчас уже вся работа идет напрямую с кирпичиками. На продакшене не всегда можно обойтись без бд с кирпичиками — хотя и можно собирать весь код заранее, чтобы потом не использовать бд, все же удобнее оказалось использовать Codegen, который часть кода выполняет из базы «на лету». (например я заранее собираю в страницу все, кроме представлений, а их загружаю уже «на лету» в зависимости, например, от скина пользователя)

aubt 5 авг 2009 в 14:50

понятно.
по-моему зацикленность именно на объеме кода у Вас излишне гипертрофирована :)
внизу mx2000 выразил то, что я думал, Вы и реализовали.
ну не вериться мне, что подключение к базе и выборка зависимостей это быстрее, чем исполнение уже подключенного кода, пусть даже часть из него «мертвого».

и что Вы подразумеваете под представлениями? я как-то не улавливаю связь между представлением (как классом) и скином пользователя. как мне видится, это просто разные шаблоны одного представления.

Napolsky 5 авг 2009 в 15:10

Хорошо, если эта тема получит продолжение, то я обязательно специально приведу более подробные и разностороннии цифры по сравнению производительности.
Да, вам правильно видится — просто разные шаблоны

tkf 5 авг 2009 в 14:38

;) деплоймент превращается в сказку, указал фтп, вбил в настройках проекта логины и пароли для доступа к базе или внешним сервисами, нажал кнопочку Gen & Upload и вуаля.
Кстати сразу видно что месье сишник.
Подход интересен, было бы интересно взглянуть на codegen, там должна быть очень интересная структура.
Кстати на основе этой системы можно вполне сделать сервис собери сайт.
Идея интересная. Ждем продолжения и подробностей.

Napolsky 5 авг 2009 в 14:54

А тем представьте еще такую вещь, если на этой базе выпустить CMS или просто пустить в массы движок:
Все пользователи движка могут коннектиться при годегене (и/или при загрузке кода «на лету») к _одной_ централизованной базе. Таким образом у всех пользователей будет последняя версия движка практически в режиме online. Или же можно просто создать что-то вроде репозитория, где будут находиться последнии версии «кирпичиков».

tkf 5 авг 2009 в 14:58

Но ведь и обновлять им после этого все придется.А я думаю перезаливка пусть и оптимизированных сгенерированных файлов будет не очень быстра. Опять же отслеживание совместимости между кирпичиками разных версий. Скорей всего будут отдельные репозитории. ^_^
Но идея интересная. Хотя мне кажется что такая CMS будет требовать несколько извращенного подхода к использованию

Napolsky 5 авг 2009 в 15:16

так в том то и суть, что пользователю не придется ничего заливать и ничего не придется самому обновлять! пользователь будет иметь коннект ко внешней базе, где будут лежать обновления. Codegen коннектиться к этой базе и генерирует пользователю код «первой свежести». При том запуск кодегена может происходить автоматически, при обнаружении обновлений. И никаких вам закачек файлов или чего то подобного.

Про контроль версий. Не забывайте, что у кирпичиков есть атрибуты. На их основе нет никакой проблемы сделать контроль версий

david_mz 5 авг 2009 в 22:35

> На их основе нет никакой проблемы сделать контроль версий

Ой, Вы таки сначала сделайте, а потом говорите…

beetleinweb 6 авг 2009 в 07:29

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

david_mz 6 авг 2009 в 08:52

Мечтать мы тут все умеем, делать — не все, но многие. Так что оценить чужой прожект, в общем, можем.

Тем более, что _сделанного_ автором мы всё-таки не видим, топик представляет собой просто декларацию о намерениях. Что реально из этого реализовано и как оно работает — никто не знает. Как с этим работать кому-то кроме автора — мы тоже не знаем. Минусы подхода очевидны (см. коммент от murr), автор их никак не комментирует и т. д. А говорить, что на атрибутах нет никакой проблемы построить контроль версий, ИМХО, может говорить только тот, кто никогда не строил контроля версий.

beetleinweb 6 авг 2009 в 11:58

Автор вроде бы недвусмысленно, несколько раз, дал понять, что это не пустые намерения. Есть реализация. Не всего, о чём говориться, но основа есть. И рубить сплеча «ты сначала сделай, потом говори» — незаслуженно грубовато в данном конкретном случае.

Эпидемия какая-то на аргументы «вы этого никогда не делали, вы не знаете как это делать»… Просто скажите конкретно, в чём проблема с атрибутами. Нет настроения говорить по делу — может не стоит и начинать?

Кстати, murr высказался хоть и «в гневе», но всё же довольно конкретно. Позволю себе упростить его аргументы, не погрешив против истины, надеюсь:

1) Не пытайтесь усовершенствовать язык, не нравится — меняйте на другой.
2) Не ускоряйте то, что нельзя ускорить.
3) Ориентируйтесь на самое слабое звено, на самого тупого разработчика.

Хоть вопросы и не ко мне, на раз уж вы сами кивнули на этот коммент…

1) История изобретения языков знает удачные примеры, когда новый язык лишь немного усовершенствовал старый, пользовался его же компилятором, и лишь со временем для него писали свой собственный.
2) Автор пишет, что ускорение есть, даже по сравнению с кешированием. И это даже на очень молодой реализации. Глупо после этого утверждать, что чёрное — это белое, и ускорения там нет и быть не может.
3) В больших коммерческих проектах это неплохой принцип. Сам иногда ему следовал. В таких проектах вообще не место экспериментам. Ну так это же не значит, что экспериментировать не следует в принципе.

В общем и целом видно, что murr сильно обжёгся на неудачной реализации. Все же лично меня его несколько чрезмерно эмоциональные пассажи (в чём он и сам покаялся) не слишком впечатлили. Хотя безусловно, это не одни эмоции, рациональные моменты там есть. И конечно, имеет значение, что murr с этим столкнулся на практике. В отличии от нас обоих, насколько я понимаю :)

david_mz 6 авг 2009 в 12:20

> Автор вроде бы недвусмысленно, несколько раз, дал понять, что это не пустые намерения. Есть реализация.

Я думаю, правильнее будет автору самостоятельно говорить за себя. Тем более, что ни Вы (как я понимаю) ни я его кода не видели.

beetleinweb 6 авг 2009 в 12:32

А я не за автора говорю, а за себя. Своими словами, не указывая на чужие комменты без особых на то причин :) Автор же мог просто не успеть отреагировать, или ему просто надоело отбиваться в одиночку. Он ведь и не обязан биться в одиночку, вы же не откажете ему в праве на поддержку сочувствующих? :)

В общем, чем плоха система контроля версий на атрибутах и вообще на БД, то есть почему там без файловой системы не обойтись, я так и не услышал. Жаль, правда было интересно.

Кстати, написать про реализацию Napolsky обещал, если будет проявлен интерес. Даже не знаю, не отбили ли у него охоту продолжать такой жёсткой критикой. Не видя кода, как вы правильно заметили :)

david_mz 6 авг 2009 в 20:42

Дело не в файловой системе, разумсеется, версионировать можно всё что угодно. Дело в том, что ОДНИМИ атрибутами не обойтись — нужен контроль за переносим/переименованием кусков кода, нужно отслеживание авторства этих кусков, нужно версионирование проекта в целом, нужно уметь делать диффы и накатывать патчи, нужно уметь переключать текущую ветку/версию проекта, нужно чтобы при этом не терялась целостность и непротиворечивость кода (особенно в нашем случае, когда код размазан по всей базе)… То есть, нужно уметь всё то, что умеют нормальные VCS. Это отдельная и довольно сложная подсистема, которая, конечно, может использовать атрибуты и пр., но к ним сведена, думаю, быть не может.

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

Делать «хорошо» в одно лицо и в закрытом режиме… ну, не знаю, у Кнута получалось, конечно, но в общем случае априори в это поверить трудно… А реализуя «как всегда», мы получим просто большой слабосвязный кусок геморроя, о чём тут все комментаторы и говорили.

beetleinweb 7 авг 2009 в 09:47

Вот это уже по существу. Заметьте, насколько отличается от первой фразы «ой, Вы таки сначала сделайте». Теперь суть «претензии» понятна, и так же по существу можно ответить.

Никто в здравом уме не будет спорить, что VCS штука сложная, и ещё сложнее её одному написать. Да ещё на базе нестандартной концепции.

Но Napolsky нигде и не заикался вроде бы, что это легко, или что он это один планирует делать. Наоборот, было сказано: «Но я верю, что это вполне конкурентоспособная концепция, и работа в этой области может дать толчок для появления принципиально новых фреймворков и CMS, с уникальными возможностями.»

Возьму на себя смелость «истолковать», надеюсь, верно: автор своим топиком хотел привлечь других к реализации, а не пытается объять необъятное, в чём вы его заподозрили :)

Хотя и сам сделал немало, но не преувеличивает свой вклад, а наоборот, иронизирует: «велосипеды», «путь воина». Я, конечно, понимаю, что моя оценка тоже субъективна. Но как-то слишком много негативной реакции. И за что? За то что человек пробует новое на свой страх и риск, и без всякого пафоса обо этом рассказывает. Постарался уравновесить негатив :)

david_mz 7 авг 2009 в 10:01

> Но Napolsky нигде и не заикался вроде бы, что это легко

Справедливости ради — именно заикался: «Про контроль версий. Не забывайте, что у кирпичиков есть атрибуты. На их основе нет никакой проблемы сделать контроль версий».

На что я и среагировал, потому что это, ИМХО, крайне легкомысленный взгляд на подобную задачу.

beetleinweb 7 авг 2009 в 10:20

Гм. Но ведь вы сами признали, что можно и на атрибутах, и с этим нет никакой проблемы, что «версионировать можно на чём угодно»? :)

Ладно, я получил очередной урок в тему субъективности прочтения. Действительно, только автор может знать, что он имел ввиду. Надеюсь всё же, что не легкость реализации VCS как таковой, а лишь лёгкость замены нативных файлов на записи в базе в рамках концепции VCS.

Napolsky 6 авг 2009 в 12:23

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

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

david_mz 6 авг 2009 в 12:25

В общем, надо видеть реализацию. Пока ощущение… настораживающее. Я понимаю, что Вы не можете отвечать за чьи-то ощущения, но тем не менее.

mx2000 5 авг 2009 в 14:38

Осталось докрутить один маленький шаг: вместо хранения кода в БД, сделать нормальный компилятор PHP -> PHP. Т.е. на входе имеем N файлов со сложными зависимостями, на выходе -> M файлов без зависимостей и лишней мишуры. Почему автор не дошел до этой точки — остается загадкой.

scorcher 5 авг 2009 в 14:58

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

mx2000 5 авг 2009 в 15:01

А чем это не компилятор, если он разбирает исходный код в AST и потом на его основе генерит новый код? Или, по вашему, компилятор должен непременно native-код генерить?

scorcher 5 авг 2009 в 15:23

ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80
RTFM

mx2000 6 авг 2009 в 00:43

Давайте не будем, а? Русскоязычная часть википедии далека от статуса авторитетного источника. Просто примите как факт, что я описал компилятор ;-)

scorcher 6 авг 2009 в 03:48

Ой какой полиглот нашелся :)
Вы еще поди и по английски то читать умеете? Не поленитесь тогда воспользоваться ссылкой.

en.wikipedia.org/wiki/Compiler
«A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code). The most common reason for wanting to transform source code is to create an executable program.»

Вы же предложили написать компилятор, который сделает преобразование PHP в PHP. и после этого вы его называете компилятор…

Более правильного название, нежели EXPLODER, это не подходит ;)

mx2000 6 авг 2009 в 08:31

Вот Вы, видимо, читать по-английски умеете, но вникать в суть написанного не утруждаетесь. Ключевое свойство компилятора — это преобразование кода с языка прикладной области (DSL) в язык системы выполнения кода.

Скажите, Вас не смущает, что Google называет свой GWT компилятором с Java в Javascript? А то, что JSP компилируется в Java? А тот факт, что Lisp компилируется в Lisp? ;-)

На крайний случай, вспомните, что Smarty компилируется в PHP.

scorcher 6 авг 2009 в 19:06

про гугл и lisp утверждать не могу, т.к. не знаю и лениво тратить на это время…

а вот про смарти могу сказать:
Smarty code -> PHP code
или вы будете утверждать, что шаблоны смарти пишутся на PHP?

Вы же предлагаете PHP преобразовывать в PHP, просто вместо 12345 в одном файле будет написано 5! (пять факториал) файлов с разными комбинациями внутренностей.
Вот собственно этим и будет заниматься ваш компилятор? я вас правильно понял или мы о разном?

allter 6 авг 2009 в 09:13

PHP и «PHP без инклюдов» — это разные грамматики (иначе можно сказать, что PHP это такой Perl с некоторыми особенностями).

tenshi 8 авг 2009 в 16:02

посмотри в словаре переводы слов compile и translate.

называть транслятор компилятором — это всё равно, что называть копир ксероксом ;-)

Napolsky 5 авг 2009 в 15:00

средний размер кирпичика — 20-50 строк. Сколько файлов понадобиться для кода всего сайта? Ни одна тысяча ) Поэтому справляется я этой работой куда быстрее. Плюс самое важное в бд — возможность назначать «кирпичикам» атрибуты. Поэтому подобный кампилятор типа PHP -> PHP хотя и возможен, думаю выглядел бы куда сложнее и работал гораздо медленнее.

tkf 5 авг 2009 в 15:04

Можно по подробней, например какие атрибуты вы используете у кирпичиков?

Napolsky 5 авг 2009 в 15:38

например атрибут `langpack` в котором хранится (и автоматически заполняется) часть единого языкового пакета, которая необходима для этого модуля. Таким образом скорость кода никак например не будет зависеть от размера языкового пакета и сокращает размер необходимой памяти.

aubt 5 авг 2009 в 15:05

кстати, во всей этой схеме именно возможность пользоваться атрибутами меня больше всего возбудила :)

mx2000 5 авг 2009 в 15:19

Эм… я немного о другом) На входе мы имеем проект, написанный по всем канонам ООП и best practices, а на выходе — борщ нечитабельного, но быстрого (в рамках ZE) кода. Например, если в какой-то части графа юзается один-единственный статик метод некоего класса Foo::bar() — имеет смысл декларировать его как функцию. Если метод является однострочник — заменяем его вызов на inline.

пример: haxe.org/api

tenshi 8 авг 2009 в 16:11

собственно это и делают всякие акселлераторы. на выходе получается байт-код — тот самый шустрый борщ.

Napolsky 8 авг 2009 в 18:30

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

tenshi 8 авг 2009 в 19:36

могу поспорить, что пхп-шный байт-код ничего не знает об ооп ;-)

Napolsky 8 авг 2009 в 20:54

конечно не знает (хотя опять таки как посмотреть). Но по-моему мы с вами немного о разном говорим :)

tenshi 8 авг 2009 в 21:26

почему же?
в случае Foo::bar() и foo_bar() с точки зрения байт-кода — наверняка никакой разницы.

Fortop 8 авг 2009 в 20:43

Автор, бог с ними акселлераторами :)

Вы не ответили на один существенный вопрос

Вот у вас страница А, где нужна RSS лента и работа с БД.
Вот у вас страница Б, где тоже нужна RSS лента и работа с БД.

Что у вас собирается в код для этих страниц? Из вашего описания, я так понимаю, в код каждой страницы будет включен полный требуемый ими фукционал работы с БД.

Я правильно понимаю, что, например, в каждой странице, которая работает с БД, будут все вызываемые в ней функции?
Я правильно понимаю, что если у меня будет 200 таких страниц, то внутри каждой будет содержаться этот код объемом в пару килобайт?

Я правильно понимаю, что ваша методика никакая не оптимизация для проекта крупнее домашней странички (т.е. для любого проекта у которого больше 5-10 страниц)?

Napolsky 8 авг 2009 в 21:05

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

Fortop 8 авг 2009 в 21:59

Я вас огорчу.
Потому как сокращения ресурсов не будет.

Код будет дублиироваться и при кешировании. Понимаете, если у меня в 200х местах используется класс Table, то кешер его подгрузит всего 1 раз и будет использовать для всех. В вашем случае он будет подгружаться 200 раз.

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

Fortop 8 авг 2009 в 22:06

Чтобы расставить все точки над "і", давайте возьмем какую-нибудь несложную задачу, которую можно сделать с нуля за 24 часа, напишем ее и сравним.

Я понимаю, что вы можете быть сейчас заняты, но уж 2 часа в день на протяжении 2х недель вы сможете выделить? :)

А через 2 недели, берем полученные коды и проводим тестирование.

Napolsky 9 авг 2009 в 06:33

тест будет необъективен так как у нас будут разные коды, априори разной производительности. Поэтому тест стоит устраивать по другому принципу: взять «классическое» приложение (zend, wp, cms какую-нибудь) и переложить его код на мою архитектуру. И сравнить производительность. Вот это будет честный тест, не так ли?

Кстати спасибо за идею. Обязательно портрачу на это время и опубликую результаты

Fortop 9 авг 2009 в 10:47

Гм, а сравнивать «одинаковые» коды было бы крайне глупо? Вы не находите?

Или вы сомневаетесь в моей способности выдать код хоть сколько-нибудь сравимый с вашим по производительности? :)

Чем перелицовка существующего кода только вами, будет отличаться от предложенного мной варианта? :)
Ведь там вы тоже будете сравнивать свой код с чужим :) которые будут разными и «априори разной производительности» :)

Вобщем, боитесь, так и признайтесь.

Napolsky 9 авг 2009 в 13:42

>> Гм, а сравнивать «одинаковые» коды было бы крайне глупо?
>> Ведь там вы тоже будете сравнивать свой код с чужим :)

Вы абсолютно не поняли, что я имел в виду под «переложить на мою архитектуру», а уже обвиняете меня в том что я вас боюсь. Попробую объяснить на пальцах, что я имел в виду:

Я хотел взять какой нибудь скрипт (например для определенности вордпресс) и разложить его на кирпичики. Потом собрать его таким образом, которым собирает страницы мой кодеген. Таким образом мы получим не новый код, а новую компановку кода. То есть при запуске страницы будут выполнены в полной точности все строки кода, которые есть в стандартном вордпресс. В собранной версии от кодегена не будет ни одной новой строки. Просто будут убраны все инклуды и весь мертвый код. Надеюсь теперь вы меня поняли?

13i 9 авг 2009 в 16:46

воистину это — адская работа — перелопачивать Вордпресс под свою интерпретацию. проще свое написать )

Napolsky 9 авг 2009 в 18:13

ну только так можно добиться по настоящему объективного теста :)
Тем более весь и не собирался — только одну страницу. Работы часа на 3, думаю не больше

Fortop 9 авг 2009 в 19:25

Вот и чудно, что я не понял. Мне же лучше — меньше работы :)

Только не пытайтесь спрыгнуть.
Берите не вордпресс, с его удодской архитектурой, а ZF.
И вперед.

Недели 4 на компоновку вам хватит?

Napolsky 9 авг 2009 в 06:28

А вот тут вас ждет очень неприятная неожиданность: кешеры опкода не любят мелкие файлы. Такие вот ни противные. И если на классике тот же eAcsellerator даст увеличение производительности в 3-5 раз, то при монолите в 10-15 раз :)
Во вторник кстати опубликую статью, где будут рассмотрены вопросы влияния «мертвого» кода, инклудов и прочего. Заодно там будет рассмотрено как со всем этим справляется акселлератор.

Fortop 9 авг 2009 в 10:05

Я вас огорчу уже в который раз, читал я заметку Котерова :)

Но в вашем конкретном случае у вас будет не 1 файл «монолит», а 20-200 достаточно тяжелых файлов с дублированным кодом.

Будет ли это существенно быстрее чем 1200-2200 (включая фреймворк) моих файлов? Сомневаюсь.
Из-за одного простого соображения — Время загрузки в моем случае линейно
«коэффицент» * («число страниц» + «число функций» + «новая функция»)
а у вас
«коэффицент монолитных страниц» * «число страниц» * («число функций» + «новая функция»)
t = k * (ns + nf + x)
t = k2 * ns * (nf + x)
По вашей информации k/k2 = от 3 до 5.

Точку пересечения сами найдете? :)

Napolsky 9 авг 2009 в 13:50

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

>>Будет ли это существенно быстрее чем 1200-2200 (включая фреймворк) моих файлов?
В разы.

>>Время загрузки в моем случае линейно
Время загрузки чего? О каком вемени идет речь?

Fortop 9 авг 2009 в 19:17

Уф, вы немного медленный.

У Котерова сравнение — 800 файлов объемом 5мб загружаются медленее 1го файла 5мб в 22 раза. (в идеале)

На пальцах, в случае реального проекта — а) загружаться будут не все 800, а в лучшем случае 1/3 от их числа. Т.е. 300. (ну не используют на все 100% фреймворк). Более того загружаться они будут по мере надобности и всего 1 раз!
б) общий объем раздробленого загружаемого кода будет 5мб * 1/3 = 1.8мб
в) объем монолитного кода у вас увеличится в «число страниц» раз.
г) объем используемого кода ваш кодеген сокращает в 5ть раз. Т.е. 1.8/5 = 0.36 мб

Но вот эти 0.36мб у вас будут воткнуты в КАЖДУЮ СТРАНИЦУ. Т.е. уже при 10ти страницах вы загружаете в ДВА РАЗА БОЛЬШЕ кода.
В реальном крупном проекте (не домашней страничке) у вас легко будет и 20 и 40 страниц.

Вот теперь берите и проверьте что быстрее загружается 300 файлов объемом 1.8мб
или 40 файлов объемом 14,4мб. Все еще недошло?

P.S. Время загрузки того, чего вы ускоряете. Вся ваша предполагаемая экономия строится на ускорении загрузки кода. (причем строго говоря, кешер под ваш проект будет жрать памяти тоже больше, из-за тупого дублирования кода)

Napolsky 9 авг 2009 в 19:46

Вы говорите очень самоуверенно, но по моему вы немного не понимаете, как работают кешеры опкода и от чего зависит производительность.

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

Но производительность приложения зависит не от того, сколько оно кода занимает на сервере, а от скорости выполнения этого кода. То есть каждая из N страниц по предложенной архитектуре будет загружаться в разы быстрее чем при классической. И не важно сколько этих N страниц: 1,10,100 или 1000. При увеличении числа страниц будет только увеличиваться занимаемое место на диске для их кода, но это никак не будет влиять на скорость этих страниц. А производительность приложения(сайта), еще раз повторяю, складывается из скоростей каждого его скрипта (страницы). и оно не зависит от того, сколько суммарно занимают эти скрипты в исходных кодах.

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

Ферштейн? :)

Fortop 9 авг 2009 в 23:20

Жесть. Нельзя быть настолько умным как вы, это меня просто убивает.

Еще раз, повторяю. У вас не будет КАЖДАЯ загружаться быстрее. Просто потому что эта КАЖДАЯ у вас больше в размере в разы. И с ростом вашего кода в сравнении с библиотечным все будет хуже и хуже.

Смотрите. Есть 10ть базовых классов они у нас подгрузились 1 раз для какой-то страницы и все!
Затем мы в 10ти страницах используем эти 10ть базовых классов. И они (О ЧУДО) не грузяться, а используются из кеша!
Общий объем «объем библиотеки» + «объем пользовательского кода»

У вас же, есть 10ть базовых классов, но используем мы только половину. Поэтому для 1 страницы мы подгружаем только 5ть (ОПА!!! ускорение в ДВА РАЗА!!), но делаем мы это КАЖДЫЙ РАЗ для КАЖДОЙ из 10ти страниц.
Общий объем «число пользовательских страниц» * «объем библиотеки»/2 + «объем пользовательского кода»

Вы математику учили?
Графики роста времени выполнения построить можете?

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

1. Объем кода библиотеки
2. Объем пользовательского кода.

Так вот для 2го все ясно — он примерно одинаков. Вы экономите на 1м.
С коэффициентом, скажем, 10.
Но вы экономите для КАЖДОЙ ОТДЕЛЬНОЙ страницы. Но проект у нас это не одна страница.

И того у нас получается что добавляется множитель — число страниц.

У меня 1й пункт загрузится всего 1 раз.
У вас он будет загружаться столько раз сколько есть страниц, но быстрее с некоторым коэффициентом. Вы сами показали, что коэффициент примерно 10 (сокращение строк кода в итоговом проекте, хотя еще вопрос как вы меряли :)

Итого уже для 10ти страниц разницы не будет, для 20 страниц вы будете в полной жопе.

Кешер опкода грузит ФАЙЛ, а не отдельную функцию. У вас файл — это монолитная страница!
Поэтому и кешировать он будет страницу целиком! И дублирование у вас будет еще и в памяти, а не только на диске.

Теперь доступно? Или повторить на бис для альтернативноодаренных?

Fortop 9 авг 2009 в 23:26

И такой момент, скорость выполнения кода практически не зависит от размера файла.

От размера файла зависит скорость трансляции кода в байткод или машинный код.
Так вот вы пытаетесь сэкономить на времени трансляции кода.

Napolsky 10 авг 2009 в 04:45

от размера файла — почти нет (при условии кешера опкода). А вот от количества инклудов — да. Даже для кешеров опкода. Если кешер опкода на монолите даст до 10x+ до на сотни мелких файлов допустим только 3x+

Napolsky 10 авг 2009 в 04:41

хехе… Мне уже и смешно и грустно спорить с вами. Я абсолютно понимаю ход ваших мыслей, но жаль вы в упор не понимаете, что этот ход мыслей неверен. По-моему у меня в последний раз хватит сил что-либо вам объяснить.

Вы признаете, что для 1 страницы мой способ будет быстрее. А теперь скажите, как наличие еще 1000 страниц повлияет на скорость загрузки этой страницы? У нас что, изменится от этого ее байт код? Или этот байт код будет медленнее доставаться из кеша?

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

Fortop 10 авг 2009 в 05:12

Все, я не могу. Убейте меня кто-нибудь тапком.
Я ненавижу когда люди так откровенно тупят. Меня это настолько бесит, что заставляет нервничать.

Вы понимаете что ваш способ будет быстрее не для ОДНОЙ, а для ПЕРВОЙ страницы проекта!!!

А все последующие у вас будут грузится дольше!!! Потому что у меня библиотека УЖЕ БУДЕТ В КЕШЕ
и НЕ БУДЕТ ГРУЗИТСЯ. А у вас она БУДЕТ ГРУЗИТСЯ КАЖДЫЙ РАЗ!!!

Все, финиш.

Napolsky 10 авг 2009 в 05:30

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

Fortop 10 авг 2009 в 05:38

Стена там -----> убейтесь.

У вас не страница будет грузится каждый раз. У вас будет КАЖДЫЙ РАЗ ГРУЗИТСЯ ТОТ ДУБЛИРОВАННЫЙ ФУНКЦИОНАЛ, КОТОРЫЙ ЛЕЖИТ В СТРАНИЦАХ.

Те самые функции работы с БД, RSS и всем остальным. В библиотеке класс подгружается 1 раз из отдельного файла. У вас же этот класс или функция во избежания инклюдов лежит в КАЖДОМ ФАЙЛЕ. Я специально у вас уточнял этот момент.

Дошло? Или нет?

Napolsky 10 авг 2009 в 06:18

>>В библиотеке класс подгружается 1 раз из отдельного файла. У вас же этот класс или функция во избежания инклюдов лежит в КАЖДОМ ФАЙЛЕ. Я специально у вас уточнял этот момент.

ДА. Именно так

Но он НЕ будет грузится каждый раз. Он грузится один раз в кеш. После этого байткод просто достается из кеша.

Napolsky 10 авг 2009 в 06:20

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

Fortop 10 авг 2009 в 06:35

Обязательно добью. Я извращенец. А вы — доцент Авас (хотя вряд ли вы знаете и помните Карцева).

У вас есть три файла

a.php, b.php, c.php

В каждом лежит класс DB для работы с базой.

Вызывается a.php — кешируется.

вызывается b.php
Теперь внимание, вопрос — каким местом кешер уже знает, что ему не надо читать и кешировать полфайла? Да ни каким! Он тупо читает и транслирует весь файл, блин. И только сделав эту ТУПУЮ НЕНУЖНУЮ РАБОТУ, он понимает, какой он идиот и что ему не надо кешировать. Но он УЖЕ ПОТРАТИЛ ВРЕМЯ.

То же самое происходит и c.php

Еще раз повторить?

Napolsky 10 авг 2009 в 07:19

Вы все правильно говорите, но у вас неправильное представление о том, как это влияет на конечную производительность.

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

А как часто приходится выполнять код этой страницы? Десятки/сотни/тысячи раз в секунду (в зависимости от нагруженности проекта).

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

Вы поняли свое маленькое упущение?

Fortop 10 авг 2009 в 07:50

Фу, печаль. Дальше дискутировать бесполезно.
Вы не понимаете тривиальных вещей, а я не обладаю достаточной полнотой информации, чтобы убить вас окончательно.

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

В простейшем наиболее разумном случае, он на них тупо плюет. А работает с файлами. Есть include файла смотрим по ключу (причем, ключем может быть имя файла!) в кеш, если нет — читаем файл, если есть — достаем байткод.

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

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

Так что все косвенные улики говорят за 1й вариант и ваше необъективное тестирование (вы сравнивали только одну первую страницу, для которой и есть выигрыш, а надо сравнивать с учетом повторного использования закешированного кода)

Fortop 10 авг 2009 в 07:56

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

Napolsky 10 авг 2009 в 08:30

неважно по чему происходят переходы. Важен факт подключения внешнего кода.

Napolsky 10 авг 2009 в 08:34

я мало понял, из того что вы написали выше. Поэтому мне легче сказать, что будет в моем случае, ибо у меня все просто. Имея N страниц у меня будут N опкодов в кеше. Для каждой странице по одному и кешеру ничего не нужно где то дополнительно искать/подключать

sse 19 авг 2009 в 18:19

«Авас» — это еще Аркадий Райкин, уважаемый; Карцев — только потом :)

Fortop 10 авг 2009 в 06:41

Теперь как работает библиотека.

У нас есть три файла

a.php, b.php, c.php, причем каждый из них меньше размером, потому что класс БД лежит
в DB.php

Вызывается a.php, выясняется, что ему нужен еще DB.php — все это читается и кешируется.

Вызывается b.php, выясняется, что ему нужен еще DB.php, но, опа, он уже у нас в кеше. Поэтому мы его достаем из кеша и АЛЛИЛУЙЯ!

То же самое и c.php

Как итог — мы имеем на 2*DB.php килобайт меньше дисковых операций и трансляции кода.

Вы же оптимизируете как раз «лишнюю» загрузку с диска.

Поэтому для 1й(одной и первой) страницы вы получите выигрышь. Для всех последующих вы будете проигрывать.

Fortop 10 авг 2009 в 06:52

тьфу, «выигрыш» конечно же, без мягкого знака.

Fortop 10 авг 2009 в 06:59

Фу, как я зол.

Мое спасение

www.youtube.com/watch?v=vcMJlTjzZgs
www.youtube.com/watch?v=iA9SODrrQwU
www.youtube.com/watch?v=zucZ5LEuTcI

пользуйтесь.

Napolsky 10 авг 2009 в 07:12

плюсик вам, помагает :D

david_mz 5 авг 2009 в 14:51

Автор, Вы не пробовали использовать autoload в сочетании с кэшем опкода и хорошей разбивкой функций по объектам? Дело в том, что при нормальном проектировании проблемы «лишнего кода, который приходится тащить» нет вообще. Нормальном — это не когда каждый файл начинается с include('common.php'), в каковом common.php сидит всё на свете.

murr 5 авг 2009 в 15:21

Многие схожие мысли приходили в голову разработчикам системы, которую мне пришлось относительно недавно поддреживать. Там тоже код хранился в базе. По итогам двухлетней эксплуатации, разработки и поддержки системы я могу сказать только одно: ВСЕГДА ХРАНИТЕ КОД В БД, И НИКОГДА В ФАЙЛАХ*.

* потому что вы ненавидите этих паршивых никчемных лузеров-программистов, которые будут еб%#$ся с вашей системой, правда?

Опишу некоторые фенечки хранения кода в БД, на своем опыте:
1) Разработчикам пришлось релизовывать свой лоадер для кода, который очень скоро перестал поддерживать новые фичи развивающегося языка. Это мелочь, но ее нужно кому-то поддерживать!

2) Контроль версий — полный пиз#@ц. На основе БД бравые разрабочики слабали свою систему контроля версий. Постоянные кошмары «кто затер мой код?», постоянные проблемы с обновлениями у заказчика и т.д.

3) Еще один уровень абстракции — еще больше проблем на задницу. Т.к. продукт кроссплатформенный, то отгребали по полной проблемы интреграции на каком-то секретном сервере заказчика между каким-то линуксом (потом стало известно, что это РедХат), каким-то апп-сервером и некой БД. Поползли кодировки в цепочке вызовов Юзер-Сервер-ОС-Бд.

4) Полная задница с получением актуальной версии кода в сложной системе, в итоге-то, его все равно нужно представить как-то в файловой системе для редактора/ИДЕ. Зависимости кода в базе от другого кода в базе становятся такими неочевидным, что просто ужас.
Ваше «сведение «мертвого» кода к нулю» — это миф, код организуют в библиотеки не просто что бы в одном файле лежало, а по неким принциам (не важно какая парадигма) и зависимостей там с лихвой.

Ваши аргументы:
Скорость достигается кешированием и прекомпиляцией, а не перекладыванием работы с обычной файловой системы (нтфс, экст3?) на базу данных. «Старый файловый способ» в вашем случае в миллион раз лучше тем минимум тем, что скорость растет от замены ФС, не меняя НИ строчки кода.

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

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

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

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

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

murr 5 авг 2009 в 15:24

Простите, тут много несвязных мыслей, писал в конце рабочего перекура, торопился и брызгал слюной от гнева :(

murr 5 авг 2009 в 15:48

В общем, еще раз, для тех, кому многобукав или маловремени:)

1) Если язык либо задачи заставляют изобретать некие мета-паттерны/интерпритаторы над языком — следует посмотреть либо на смену языка/парадигмы, либо на смену архитектуры (либо на природу сходить, кваса попить и птичек послушать). Можно посмотреть питон или руби, прекрасные языки позволяющие делать метапрограммирование простой задачей, с хорошим сообществом. Попытки изобрести мета-интерпритатор интерпритируемого языка — плохие попытки. Попытки упростить архитектуру (в первую очередь для человека!) до максимума — хорошие попытки.

2) Ускорение работы системы в цепочках: Пользователь <-> Программа, Программа <-> Данные, Программа <-> Окружение, Данные <-> Окружение должно приходится на первую и вторую связь (грубо говоря: оптимизация работы самой программы c данными, оптимизация работы программы у клиента, а программа и данные в идеале должны быть максимально независимыми от окружения (в данном случае, php спокойно позволяет это делать). Попытка найти скорость там, где ее нет (аудиофилы могут расказать вам о «чистейшей безкислородной меди» в обычном полутораметровом сетевом кабеле за 500 баксов) — это плохой прием оптимизации. Кеширование или ускорение доступа к данным без существенного изменения кода — хороший прием.

3) Пока разработчиков раз, два и все — вроде бы все хорошо, но когда их пару десятков в разных городах — сложность поддержки системы возрастает по функции n^(n1-n2)*q, где n — общее число разрабочиков, n1 — число людей ДОСКОНАЛЬНО знающих архитектуру и код, n2 — число людей, плохо знающих архитектуру и код, а q — показатель тупости самого глупого разработчика. Ориентация на простоту для машины (в данном случае мнимую) — плохой прием. Ориентация на простоту поддержки и модернизации для пользователей системы (да, для самых тупых из них) — хороший прием.

murr 5 авг 2009 в 15:54

Ммм, функцию намудрил:
сложность = n ^ (n — n1) *q, где
n — общее число разрабочиков,
n1 число людей, плохо знающих архитектуру и код,
а q — показатель тупости самого глупого разработчика.

Goodkat 6 авг 2009 в 08:57

наоборот

scorcher 5 авг 2009 в 15:28

почти со всем согласен! :)

> Чем из наиболее мелких и простых частей состоит конструктор, тем…

чем проще кусок кода — тем более понятен он программисту. Это не значит, что он должен быть маленьким… он может быть и большим, но должен быть логичен.

david_mz 5 авг 2009 в 16:14

Была бы карма, плюсанул бы от души.

coldFlame 5 авг 2009 в 15:31

Автор, вы когда-нибудь слышали о системах контроля версий?
А об оптимизаторах-прекомпиляторах типа APC или Zend Optimizer?
А ничего, что файловая система — это и так база данных, которая хранит в себе файлы?

coldFlame 5 авг 2009 в 15:32

В общем поздравляю, модульное программирование вы для себя уже открыли, развивайтесь дальше. :)

Napolsky 5 авг 2009 в 15:43

на нападки обычно не отвечаю, но здесь лишь отмечу ту мысль что да, имея опыт как ООП так и компонентного программирования, в php я осознанно сделал шаг назад в сторону модульного программирования.

coldFlame 5 авг 2009 в 15:45

Я не нападаю, правда. Я предложил темы, которые могут быть вам интересны: APC, Zend Optimizer, SVN, git.

IntenT 5 авг 2009 в 15:52

феерический ппц

crocodile2u 6 авг 2009 в 06:59

… а судя по тому, что в комментариях есть и добрые отзывы — становится все ппцатее и ппцатее…

Napolsky 6 авг 2009 в 07:14

Знаете, все ужасаются от хранения кода в бд. Но здесь не маловажна доля предубеждения. Все слышали о том, как это ужасно, многие даже видели провальные попытки хранения _части_ кода в бд с ее евалом.
Но никто не пытался это реализовать на полную(говорю «на полную», потому что мне не известны случаи, когда как и в моем подходе в бд хранится абсолютно весь код, и при этом есть возможность вообще не использовать eval ) и посмотреть чуть глубже. Я же попробовал. И доказал (по крайней мере себе) что такой вариант имеет право на жизнь. Разве это плохо? :)

volk113 6 авг 2009 в 07:23

Знаете, все ужасаются, то сложно ходить привязав руку к ноге, а ногу к уху. Но здесь не маловажна доля предубеждения. Я же попробовал. И доказал (по крайней мере себе) что такой вариант имеет право на жизнь. Разве это плохо? :)

AxisPod 6 авг 2009 в 07:29

А вы знаете, есть такая наука под названием Комбинаторика и теперь возьмем 200 различных функций, и предположим что все пересечения способны на жизнь, это где ж такой винт то взять чтобы все варианты поместить, это получается 200!=..., имхо просто баснословная циферка.

crocodile2u 6 авг 2009 в 10:58

Вся ваша затея вышла из незнания того, что существуют решения, позволяющие ускорить выполнение PHP-кода, не прибегая к садомазохизму. APC, eAccelerator кэшируют в памяти сервера готовый байт-код.

Кроме того, вы, очевидно, работаете один, это видно из того, что ваш подход означает не просто общий «феерический пипец » (с) ИнтенТ — он означает еще и капитальный пипец хранению версий, разрешению конфликтов: то есть вообще командной разработке.

Я так считаю — сделали для себя такое чудовище — ну подождите, посмотрите на него. Оно чуть погодя проснется (это я вам гарантирую) и надерет вам задницу (и хорошо, если вам, а не кому-то еще, кто будет разгребать за вами эти Авгиевы конюшни). А вы сразу — «вот смотрите, что я сделал, что я сделал». Щас ведь еще стопицот пионеров побегут на работу с криками «теперь мы знаем — надо хранить код в БД!»

tenshi 8 авг 2009 в 17:06

основная беда подобных препроцессоров заключается в отсутствии адэкватного бэктрейса…

zupernintendo 5 авг 2009 в 15:58

Данный подход можно использовать без извращений с БД — с помощью макросов.
Есть уже готовые препроцессоры — универсальный M4 и препроцессор языка С.

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

standov 5 авг 2009 в 16:00

не представляю разработку без автодополнения в IDE

AgaFonOff 6 авг 2009 в 08:39

Вы что, не в Far-е кодите?

standov 6 авг 2009 в 09:48

чур меня

Groove 5 авг 2009 в 17:03

Увеличение скорости работы приложения за счет скорости работы программиста, трата времени на создание инструментов УДОБНЫХ для отладки и программирования этих блоков, увязывание всего этого в голове для начала, опять же именно работа с БД обычно является узким местом при разработке. Бррр, уже страшно!

>>Время генерации страницы сократилось с 0.25-0.3 до 0.04-0.05 секунды
>>(~600%. Напоминаю, что это без кеша в классике. с кешом цифра будет поменьше)
Указанное Вами время генерации страницы является достижимой целью при правильной настройке сервера, как уже было сказано выше. Кстати, для интереса — включите кеширование, насколько меньше станет время генерации?

Но чисто за реализацию этой идеи — браво, все говорили об этом, но попробовать ни у кого руки не доходили! Спасибо!

duncanf1 5 авг 2009 в 17:57

Статья должна начинаться так:
Работодатель вас гнобил и унижал? Вовремя не платил и выжимал все соки? Терпение кончилось и вы уже почти ушли, но хочется напоследок оставить о себе память? Но как же принести наибольшее количество проблем, формально оставшись в правовом поле и даже завершить текущие проекты.
Я расскажу вам как!

Мне как то достался сайт на typo3 c кучей кода сохраненной в БД. Хотя человек который его сделал действовал из лучших побуждений, тоже был «изобретатель» :)
А так минусы вы указали верно, только добавить про контроль версий и невозможность работы в команде.

funca 5 авг 2009 в 18:52

Посмотри Zope. Там используется подобный подход. В документации описаны случаи когда выгоднее хранить исходники в файлах, а когда в БД.

Невозможность полноценно использовать IDE

Напиши webdav интерфейс, отдающий исходники из БД, подключай этот ресурс как сетевой диск и используй любую IDE, работающую с файлами. Это сильно проще, чем писать текстовый редактор.

energycsdx 6 авг 2009 в 07:18

в Zope исходники хранятся на файловой системе.
возможно вы имели ввиду объекты Python script, Page Template которые дают возможность создавать скрипты через веб интерфейс, но реально не используется в больших проектах

WarGasm 5 авг 2009 в 18:58

Автор как то не правильно понимает то как работают объекты. Мы как то проводили эксперимент. Два объекта: у первого 40 методов, у второго 200, вызывался один лишь метод каждого объекта в цикле на 10 млн. итераций. Разница в процессорном времени и памяти на столько мала, что огород из кусков кода в бд видится бессмысленным.

ashofthedream 5 авг 2009 в 22:39

Ох как жестоко…

У меня конечно тоже, иногда, после профайлинга с просмотром покрытия кода тоже возникают странные мысли о том, что слишком много лишнего кода имеется… но чтоб такое.

Если посмотреть на вашу схему то сразу видны косяки, которые сводят на нет все видимые плюсы — в комментариях выше их уже описали.

А собственно пришел я вот к чему — банальное использование fastCGI. Имееца загрузчик который собирает наше приложение — загрузилось, отлично. Теперь висим как сервис и роутим запросы на наши контроллеры и что-то выполняем. Быстро, просто да и крависиво.

okopok 6 авг 2009 в 05:55

ВЕЛОСИПЕДИЩЕ! :))))

cron 6 авг 2009 в 06:11

Простите, а чем реализована подсветка кода в веб-интерфейсе?

Napolsky 6 авг 2009 в 06:47

на codepress (http://sourceforge.net/projects/codepress/). Правда пришлось его переписать чуть менее, чем полностью :)

Varnak 6 авг 2009 в 06:13

Расширяемость такого решения под большим вопросом.
Особенно когда на горизонтальную денег нет, а узкое место это бд.

Old_Chroft 6 авг 2009 в 06:26

За хранение «живого» кода в БД нужно бить, причем не только по рукам.

yuretsz 6 авг 2009 в 06:31

Я бы такой код на поддержку не брал. Один eval чего стоит.

yuretsz 6 авг 2009 в 06:38

Зато это отличный способ сохранить рабочее место! Захерячил весь код в базу и больше никто кроме тебя в нем не разберется. Профит!

Samiel 6 авг 2009 в 06:35

Как эксперимент — забавно, но в продакшене…
Режешь левую резьбу на гайке — будь готов резать такую же резьбу на всех болтах.

danilissimus 6 авг 2009 в 06:56

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

coldFlame 6 авг 2009 в 10:04

это называется «кеширование»

TWINc 6 авг 2009 в 07:12

А какой смысл убирать «мертвый код»? У вас там чтоли доисторический сервер, который часами парсит php и при этом жудко тормозит?

Napolsky 6 авг 2009 в 07:20

Нет, конечно же не часами. Но ради интереса проведите такой эксперимент: создайте файлы на 2000/5000/10000 строк пхп кода (просто объявление функций, без какого-либо выполнения). И натравите на них ab (ApacheBenchmark). Вы увидите, что количество запросов в секунду обратно пропорционально коду в файле :) Я не говорю, что на этом можно реально много выиграть на практике (проблему решают кешеры кода отчасти), но на это тоже стоит обращать внимание. Хотя бы в исследовательских целях

TWINc 6 авг 2009 в 08:21

stas@dev ~ $ cat test.php

TWINc 6 авг 2009 в 08:27

мда круто хабра вырезает теги из сообщения, я не виноват :))

stas@dev ~ $ cat test.php
?php

echo '?php class foo {';

for($i = 0; $i < $_SERVER['argv']['amount']; $i++) {
echo 'public function test'.$i.'() {}';
}

echo '}';
stas@dev ~ $ php test.php --amount 2000 > 2000.php
stas@dev ~ $ php test.php --amount 5000 > 5000.php
stas@dev ~ $ php test.php --amount 10000 > 10000.php
stas@dev ~ $ time php 2000.php

real 0m0.016s
user 0m0.008s
sys 0m0.008s
stas@dev ~ $ time php 5000.php

real 0m0.016s
user 0m0.016s
sys 0m0.000s
stas@dev ~ $ time php 10000.php

real 0m0.016s
user 0m0.016s
sys 0m0.000s

david_mz 6 авг 2009 в 09:11

То есть, Вы признаёте, что поднятая Вами «проблема» вполне решаема стандартными способами, но в исследовательских целях захотелось извратиться?:) Замечу, что «извратиться в исследовательских целях» — дело более чем благородное, только надо и позиционировать это именно так.

P. S. Открыл самый большой класс моего проекта, который мне крайне не нравится своей раздутостью. 1500 строк. Остальные классы — строк по 200-500 в среднем. А Вы действительно постоянно имеете дело с файлами по 5-10 тыс строк?

Napolsky 6 авг 2009 в 10:41

Да, я конечно признаю, что проблема (по крайней мере проиводительности) решаема связкой OOП-акселлератор-кеш. Правда не стоит сбрасывать со счетов «плюсы» атрибутов кусков кода и возможности произвольной модификации кода перед выполнением. И да, я во многом работал над этой системой именно в исследовательских целях. Это было что то новое и свежее, от чего я получал удовольствие :)

Насчет строк кода: я имею ввиду строк кода на странице, которые приходится парсить php. У вас же на странице не один класс, правда? ;)

david_mz 6 авг 2009 в 11:19

Модификация кода — это палка о двух концах. Обычно речь о модификации кода заходит при недостаточно продуманной объектной модели, когда не получается расширить какой-то функционал обычным образом и приходится «патчить» код или вывод. Чревато большими проблемами при отладке и рефакторинге…

На странице (у меня нет понятия страницы в чистом виде, но пусть будет «при обращении к определённому урлу») у меня обычно классов, наверное, пять-шесть… Собственно контроллер запроса, шаблонизатор, ну и пара-тройка классов модели. При том что весь код уже лежит в кэше опкода.

Fortop 6 авг 2009 в 11:26

Вот в этом «я имею ввиду строк кода на странице, которые приходится парсить php»
я и вижу грабли. (писал ниже в комментариях)

Дело в том что в случае опкодкешеров код парсится для каждого класса 1 раз при загрузке. И затем используется сколько угодно.

У вас же будет как минимум дублирование объявлений классов и функций на каждой странице.
А если не будет дублирования объявлений (например, за счет уникальных имен), то получите дублирование кода.
Парситься это все будет «надцать» раз, например, класс работы с БД используется в 100 страницах и в каждой!!! странице он будет присутствовать. Где здесь ускорение работы? :)

P.S. Т.е. до тех пор пока код фреймворка больше чем ваш проект, у вас будет небольшое ускорение. Как только они сравняются, или ваш проект станет больше… ускорение станет торможением.

Napolsky 6 авг 2009 в 11:43

дублирование классов и функций ни в коем случае не будет (так же как и дублирование кода под разными именами). Да и сам php даже не позволит вам продублировать функцию или класс и вылетит с ошибкой

Fortop 6 авг 2009 в 13:08

Ну простите. Как это не будет?

Вот у вас страница А, где нужна RSS лента и работа с БД.
Вот у вас страница Б, где тоже нужна RSS лента и работа с БД.

Что у вас собирается в код для этих страниц? :) Из вашего описания, я так понимаю, в код каждой страницы будет включен полный требуемый ими фукционал работы с БД. И не дай бог эти две страницы у нас еще и позволяют редактировать БД, то это тихий капут.

immaculate 6 авг 2009 в 07:28

Я не понял, может невнимательно читал, но все же — кто отслеживает зависимости между частями?
Как обеспечивать хранение версий, типа как в системах контроля версий а-ля git и mercurial?

Napolsky 6 авг 2009 в 09:01

здесь тоже все очень гибко. Вы можете настроить централизованную систему управлениями версиями под свои нужды. Можете как в CVS разрешить редактирование одного кода многими разработчиками. Можете настроить так, что каждое новое изменение будет «пораждать» новый кирпичик (а в атрибуты ему например писать кто и что конкретно изменил, добавить текущю версию ). При том опять таки можете заставить собирать кодеген код из «кирпичиков» нужных версий, или нужных авторов. Вообще сама суть, что бд становится как бы нативной, открываются широкие возможности для отслеживания изменений кода или многопользовательской работы над ним

flashvoid 6 авг 2009 в 07:38

А вот мне скоро достанется управлять провайдером у которого биллинг и внутренний документооборот так написаны, пхп в базе, дельфовый клиент для рендера, данные и код в одной базе, про параллельную разработку никто не слышал, контроля версий нет вообще.
Страаашно. Но уже лет 6 работает как то…

deerua 6 авг 2009 в 07:47

А можно глянуть на живой прожект? ;)
зы: если боитесь хайглоад, можно и в личку, буду очень признателен ;))

Napolsky 6 авг 2009 в 09:05

отправил

Zlogrom 6 авг 2009 в 09:48

отправьте и мне, интересно было бы.

Anikin 6 авг 2009 в 18:02

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

Napolsky 7 авг 2009 в 05:27

отправил

rubyrabbit 6 авг 2009 в 07:50

В PunBB 1.3 похожим образом реализован механизм расширений.

golubeff 6 авг 2009 в 07:56

Сколько у вас запросов к базе генерится? Если один, то какой у него план запроса?
Я что, тут один думаю, что при >2 посетителей в сутки вся эта система ляжет от нехватки производительности?
В любом худо-бедно нагруженном проекте люди снимают нагрузку с базы, перенося всё на файлы, а вы идете наоборот.
Ну, может, в качестве эксперимента это и прикольно. Но не для producation-использования, это точно.

Napolsky 6 авг 2009 в 09:06

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

g00d 6 авг 2009 в 07:59

Автор молодец! наверно не один час на это все ушел, смел и силен!
Я для себя нашел в этой заметке что на основании данного принципа можно делать очень гибкую систему прав доступа.
Однако выскажу свою точку зрения, которой ей я придерживаюсь —
Когда что то изобретаешь это должно быть ну очень очень крайне простым — тогда это то было или есть кому то нужно.
Знаете для того что бы выполнить задачу А, вам нужно выполнить еще с десяток операций это «не красиво» а значит не удобно, не просто и нафиг не нунжо.
Все гениальное — просто. Ведь есть же какой-то смысл в этой фразе?
Ваше направление мысли я думаю интересное, по вот способ ее решения в рамках данного языка, боюсь может быть применим но только в узком сегменте.
Но все равно — работа проделана огромная — Вы молодец!

lovchy 6 авг 2009 в 08:02

Самое страшное качество для программиста, который пытается играть роль архитектора — недостаточный анализ поставленных задач. И, как следствие, недостаточный анализ альтернативных решений. Идеи хорошие, верные. Направление категорически безумное. APC, ZO и __autoload решают эти проблемы стандартными способами — это раз.

Файлы хороши еще тем, что они — стандартная входная сущность для миллиона утилит. Кроме того, что человеку пришлось писать свой фреймворк для такого подхода, ему пришлось писать свой редактор кода на JS! Я бы стрелялся не от идеи хранить код в БД, а от идеи писать код в браузере. Реальные пацаны не используют отладчики и консоль? Вы понимаете, что сэкономив микросекунды работы компилятора PHP (забудем про APC на секунду), вы будете писать код, который невозможно будет удобно оптимизировать? И нам этом вы потеряете куда больше производительности.

А еще, загрузка дисковой подсистемы на обработке кода ОЧЕНЬ легко масштабируется и ОЧЕНЬ дешево. А вот СУБД на порядки сложнее. И я говорю не про отдельную систему, а про идею с «универсальным репозиторием кусков кода».

И алаверды, не надо поощрять людей, которые де «мыслят нестандартно». Когда люди выдумывали колесо, наверняка были и треугольные варианты. То, что в 2009 году пришел человек и сказал: «я сделал треугольное колесо!» безумие ровно до тех пор, пока треугольное колесо хотя бы отдаленно не приблизится по качеству к круглому. И вот _тогда и только тогда_ его можно хвалить за нестандартное мышление. А до тех пор — учим матчасть.

immaculate 6 авг 2009 в 08:44

Да тут на «сложные» вопросы не отвечают, похоже.

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

Napolsky 6 авг 2009 в 09:24

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

Но не кажется ли вам интересной та мысль, что ту скорость, которую в обычном случае мы достигаем только с помощью акселлераторов и кеширования, мы получили БЕЗ них (как минимум экономим память)? Хоть и какой ценой, но все же.

Fortop 6 авг 2009 в 11:12

Ммм, а проверить?

Гложут меня смутные сомнения. Что кеширование вашего «монолитного» кода без мусора будет менее эффективным, чем кеширование фреймворка с его массой инклюдов.

lovchy 6 авг 2009 в 11:33

Акселераторы решают эту проблему без моего участия. Если проблему можно одинаково решить прозрачно для меня и непрозрачно для меня, прозрачное решение всегда лучше.

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

Опять же, я не писал, что вы плохой. Я писал, что не надо вас поощрять. Такие эксперименты — это прикольно. Только не надо их показывать общественности. Тут сейчас набежит дровосеков, которые так и будут впредь писать свой код. Вы то может и не проанализировали существующие решения достаточно. Но думать явно умеете. И создание правильных решений — просто вопрос опыта и развития. А дровосеки тупо копируют. И это скопируют. А потом появляются всякие NetCat'ы.

Napolsky 6 авг 2009 в 11:45

>> Только не надо их показывать общественности
Вот тут я с вами буду в корне не согласен. А «дровосеки» всегда и так найдут, где и как им наломать дров :)

ESQUELETO 6 авг 2009 в 08:04

Но подождите. Файловая система это же и есть БД…

Talleyran 6 авг 2009 в 08:07

0.04-0.05с это дохера мой друг. Причем это время будет расти, вместе с количеством запросов, потому что в вебе надо _как можно больше кешировать_, а если кешировать, то к чему весь этот огород.
Когда мой «мега» движок стал мне не нравиться, когда я понял что мне нужна красивая модель работы с шаблонами, когда мне захотелось ООП (заметьте буквы большие), я подумал: «А не попробовать ли мне что-нибудь другое» и это был ruby.
php сам по себе гавно… а как им пользуются так это вообще ппц.
Что до кода в бд — можно, почему бы и нет — это динамические языки, это метапрограммирование, вопрос лишь в том «как использовать?». Ответ: сериализация объекта: хранение объектов и методов, связанных только с этим объектом.

Napolsky 6 авг 2009 в 09:16

0.04-0.05 это смотря для чего «докуя». А учтите еще, что эти цифры были получены без использования какого либо кеширования и на самой первой стадии разработки этого движка. Сейчас они снизились еще как минимум вдвое, и время «накладное» время генерации страницы практически равно 0

Talleyran 6 авг 2009 в 09:34

запрос в БД тоже 0? Постройте график: время генерации от количества запросов. О каком кешировании вы говорите? После кеширования должна получаться статика, которая отдается фронтэндом. Вот тогда время генерации точно 0, потому что ее вовсе нет.

Napolsky 6 авг 2009 в 09:43

При чем тут запрос в бд? почитайте комментарии выше: на выходе из Codegen мы имеем монолитный код страницы, который уже не требует никаких запросов к бд движка. Это важно. При запуске страницы бд движка уже не нужна.

Talleyran 6 авг 2009 в 09:52

хм… почитав ваши комменты, эта система больше напомнила мне IDE нежели CMS…

Napolsky 6 авг 2009 в 09:59

эта система ни в коем случае не CMS! Это даже сложно назвать фреймворком. Это просто концепт архитектуры, некое «ядро». Да, на ней написаны подобия CMS, есть ни один рабочий проект, но здесь я специально пытался показать максимально далеко от них, передав только саму суть.

Talleyran 6 авг 2009 в 10:05

Просто вы начили с CMS…
Если под данную архитектуру легко пишутся расширения, то имеет право на существование…
Тогда интересно посмотреть на работающие проекты а так же (повторюсь) можно ли посмотреть скрипт редактора?

Napolsky 6 авг 2009 в 10:20

не помню, где я начинал с CMS, ну да ладно. Под данную архитектуру легко пишутся «кирпичики», а вот то насколько легко будут в систему импортироваться какие то модули и прочее — зависит от codegen, ведь это его работа «строить». Ссылку на примеры отправил в личку. Ссылку на редактор уже 2 раза оставлял в комментах.

jeje 6 авг 2009 в 08:09

>php сам по себе гавно… а как им пользуются так это вообще ппц.
Не язык делает код, а программист, говно программист = говно язык.

Talleyran 6 авг 2009 в 08:21

>Тут все просто и понятно: каждая отдельная функция, класс (а лучше даже метод класса), контроллер модуля, представление модуля и т д — это отдельная строка в бд.

Программист что ли виноват в том что в php нет способов расширить класс иначе чем наследованием, реализовать структуру модулей/классов… это все от тупости языка.

jeje 6 авг 2009 в 08:24

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

Talleyran 6 авг 2009 в 08:34

К чему эти метафоры.
Попробуй другие языки: руби, питон.
Попробуй фреймворки, хотя бы чисто из интереса. Например Merb. Посчитай строки. Может вовсе и не надо хранить код в БД, может его можно грамотно организовать, включив только нужное…

jeje 6 авг 2009 в 08:44

Вы уж просите но я начинал с С++, и не плохо вояю на .NET. Мне есть с чем сравнивать, но любую технологию нужно уважать.

zw0rk 8 авг 2009 в 16:31

> любую технологию нужно уважать

вот это неверно, кстати. особенно, если вне контекста IT.

lovchy 6 авг 2009 в 08:35

Вы не понимаете почему monkey patching в ruby — это не только хорошо, но и плохо. Читайте кучи тредов про это. А заодно про множественное наследование в C++. Это раз.
Сходите посмотрите сравнение скорости Ruby (а также JRuby и IronRuby) с PHP. Это два.
Почитайте про историю развития языков программирования. Это три.

Тогда с вами можно будет о чем-то говорить.

Talleyran 6 авг 2009 в 08:47

Причем здесь блять c++, monkey path и множественное наследование, в руби есть миксимы (примеси) — модули которыми можно расширить класс, и даже объект. В руби есть пространства создаваемые этими модулями типа Module1::Module2::Class1.
Где требуется скорость — там пишут расширения на c и с++.

lovchy 6 авг 2009 в 08:48

Мой любимый язык — ruby. При этом я понимаю где и почему он лучше чем другие. А где хуже. А вы просто мартышка, которая прыгает и кидается какашками. Беспощадно и бессмысленно. Кыш с ветки!

Talleyran 6 авг 2009 в 08:58

>Тогда с вами можно будет о чем-то говорить.
кто из нас кидается какашками.

>Мой любимый язык — ruby.
Гон это. Всем очевидный, стремный гон.

l2k 6 авг 2009 в 14:59

Программист виноват в том, что не умеет правильно использовать то, что есть!

Talleyran 6 авг 2009 в 08:29

кстати респект за редактор, сам вынашиваю эту идею (не совсем так конечно).
Не поделишься скриптом, интересно как ты реализовал подсветку синтаксиса, и на сколько все это шустро работает?

symbiosislab 6 авг 2009 в 08:27

А что за веб IDE такая у вас установлена с подсветкой синтаксиса?

Napolsky 6 авг 2009 в 09:13

уже отвечал в комментах выше: веб IDE, если можно ее так назвать, реализована на ExtJs + переделанном codepress (http://sourceforge.net/projects/codepress/)

Joes 6 авг 2009 в 09:04

Мне уже страшно. Ошибка при валидировании ввода, SQL injection и запуск произвольного кода на сервере?
Нет, спасибо.

DEbuger 6 авг 2009 в 10:01

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

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

Насчет того, что на выходе мы получаем файл пхп, а зачем он мне на выходе? Может все таки лучше на выходе получить готовую страницу в ХТМЛ и положить её в мемкеш. Тогда мы убьём одним выстрелом нескольких зайцев:
1. Поиск файла в файловой системе
2. Распарсивание его интерпретатором
3. Выполнение
4. Вывод данных.
5. Опционально в мемкеш мы можем скаладывать страницы готовые, непосредственно в момент когда редактор нажал сохранить.

Получаем такую цепочку:
1. Парсим запрос
2. Находим в мемкеше
3. Отдаём пользователю.

Вот и скорость буквально молниеносная.

Napolsky 6 авг 2009 в 10:33

>>Я так понимаю автор сам хочет распространить свою технологию. Дак почему же тогда вы не выложили свой код с примерами

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

>> ООП перекрывает потребность в этом конструкторе
Подобное (по производительности) получается только при связке (ООП+акселлератор+кеш подключаемых файлов). Не интересна ли мысль получения похожего результата без этой связки?

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

DEbuger 6 авг 2009 в 11:07

Просто ваш способ исключает как писали выше, командную разработку, убирает IDE, приходится разрабатывать самому контроль версий. Чтобы все это вернуть нужно написать все окружение для своего подхода с нуля. Отсюда возникает резонный вопрос, почему пхп? Можно было на C++ полноценный скриптовый язык, который хранил бы свои процедуры в базе данных.

Napolsky 6 авг 2009 в 12:38

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

DEbuger 6 авг 2009 в 12:53

Ну тогда подскажите как собирать из чужого кода нарезанного на кусочки? Мне кажется это очень затруднено, в том плане что если я впервые вижу какой нибудь объект, и не знаю как оно работает, я открыл файл посмотрел уловил логику, а в вашем случае нужно изучать отдельные структуры объекта, и собирать их в цельный объект. Или все таки речь идёт о функциональном программировании? Кстати да, в таком способе как вы сделали он подошёл бы во многом лучше чем ООП.

НЛО прилетело и опубликовало эту надпись здесь

kalyaka 6 авг 2009 в 10:24

Чем-то ваша идея напомнила систему хранения исходных текстов в ABAP Netweaver (сервер приложений в SAP ERP). Там тоже все хранится в таблицах СУБД (не только исходный текст, но и шаблоны отчетов, структуры таблиц ...). Если нужно расширить какой-то стандартный код, не ломая систему (т.е. не правя непосредственно код саповских разработчиков), то можно создать свой хук, назначив его выполнение перед точкой входа в стандартный модуль (или в конце выполнения) — т.н. «логическая привязка» (а не абсолютная, по номеру строки, например), а там уже codegen, перед непосредственным выполнением модуля, соберет все ваши хуки и оригинальный исходный код в одну выполняемую единицу. Очень удобно.

ConstNW 6 авг 2009 в 10:28

Пишите уже сразу компилятор на пхп. Чо уж там.

ItGold 6 авг 2009 в 10:33

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

garex 6 авг 2009 в 10:44

Для одного человека возможно, а для N — крайне тяжко.

В-принципе идея ясна, но альтернативы можно лучше реализовать:
— заместо БД использовать SVN и уже оттуда вытягивать нужный код, необязательно с БД, каким-нить замороченным скриптом;
— использовать акселераторы, которые по-мойму фактически тоже самое делают, но лучше;
— тупо кэшировать.

Ну и напоследок пипец-вариант: генерить сайт в виде HTML`ек и внутри него делать так, чтобы динамические части также регенерились, где это реально. Напр., страница комментов может, а уже поиск — нет.

Trial 6 авг 2009 в 10:52

Прочитал первый абзац, сразу возник вопрос — а как же FastCGI? По моему синтаксический анализ кода для КАЖДОГО запроса — это давно анахронизм, по крайней мере для крупных проектов. У меня в движке, например, код парсится один раз, и потом просто подгружаются (и кэшируются) нужные модули по мере поступления разнообразных запросов. Можно возразить что это все потом сидит в памяти — но ничего страшного в этом нет, как правило при времени генерации страницы 0.1 сек достаточно всего порядка 10 экземпляров для отдачи до сотни страниц/сек, и вообще память сейчас не проблема.

А вообще автор молодец, взял на заметку это нестандартное решение, может где нибудь пригодится.

egorinsk 6 авг 2009 в 13:24

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

Во-вторых, вы пишете про «неиспользуемый код, edit, delete», а так ли это много? У меня каждая операция занимала максимум 20-30 строчек кода как правило, следовательно то, что мы экономим — несколько сотен строк? Это по-вашему много? Имхо, не надо опускаться до уровня функций, а остаться на уровне файлов. То есть просто склеивать файлы в один, правда при этом вся экономия — это экономия на инклюдах.

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

Из здравых мыслей — это замена строк на нужном языке. Я бы еще добавил такую штуку: например, компиляцию операций с ORM в запросы к БД, через mysql_*(). Ведь большинство реализаций ORM/DAL довольно-таки тяжелы, они в рантайме парсят запрос, разные параметры подставляют и меняют, почему бы не перенести эти операции в кодогенератор?

И воторое, что стоит оптимизировать, это шаблонизатор, как правило вывод шаблона занимает основное время (ну у меня так было по крайней мере).

Napolsky 6 авг 2009 в 13:37

>>Во-вторых, вы пишете про «неиспользуемый код, edit, delete», а так ли это много?
Вообще много, если не использовать автолоады и не разделять классы по методам. Как я привел в статье, в моем случае это было сокращение с 12 до 2 тысяч строк.

Да, предварительную обработку кода как раз можно использовать для какого либо парсинга (наиболее тяжелая операция часто). Я например на этапе кодегена парсю языковые пакеты. Можно и ORM как то облегчить.

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

egorinsk 6 авг 2009 в 13:50

Просто посмотрите, количество минусов от хранения кода в БД (или в тысяче мелких файлов) слишком велико. Редактировать код череез тормозной javascript-редактор — ад, я считаю. При этом выигрыш — всего лишь экономия на инклюдах и проверке времени модификации кусков кода при использовании опкешера (а мы все его или используем или будем использовать).

А вот если бы вы оптимизировали тормозные шаблонизаторы, генерирующие неэффективный код (и кстати там тоже можно склеивать шаблоны/плагины в одно целое), или тормозной ORM… выигрыш был бы в разы больше. Вы же не в том направлении движетесь!

А что касается добавления аттрибутов к функциям (по типу .NET/Java как я понял ) — так для этого необязатлеьно резать код и засовывать в БД, это можно делать и с пхп-файлами.

MaksimMukharev 6 авг 2009 в 21:48

Очень интересный подход и проделана большая работа похоже. Вы действительно молодец.

А что касается самого решения… Не буду повторяться про кеширование. Я рассмотрю саму идею «кирпичиков», которую как-то мало задевали в комментариях.

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

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

Какой может быть плюс у такого решения

Более простая среда разработки (можно даже медитировать по поводу автоматической генерации на основе диаграмм UML или действительно оформить свой упрощенный язык для разработки), которая может дать много бонусов

Минус

В любом случае этому промежуточному уровню нужно будет учиться. Это по сути дополнительный новый язык. И если он не будет давать серьезного преимущества для людей, которые знают PHP, то никто язык учить не будет.

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

Вывод

Идея очень даже может жить, если вы не будете чрезмерно углубляться в код. Людям нравится читать книгу, а не представлять ее в молекулярном виде. проще надо быть :-)

Ну и БД тут абсолютно не причем!

13i 8 авг 2009 в 18:32

Я три года разрабатывал почти что подобную систему.
Вся архитектура ее — конструктор, но это не фреймворк, а легко доступная для горе-юзеров CMS.
В БД лежат и могут быть добавлены/изменены/удалены через админку:
— дизайн (шаблоны в HTML)
— стили CSS
— блоки (небольшие куски информации, как статичные, так и автоматически сменяющиеся с кучей настроек)
— разделы, включающие папки и страницы и полностью настраиваемые
— и многое другое (дополнительные таблицы БД, списки, шаблоны)

Все еще не перекинул JS в БД. И еще не испытывал PHP вставки в блоки, хотя такая функция уже написана.
Есть резервная копия всей базы с автоматическим архивированием.

ЧТО это дает CMS — сама CMS остается универсальной и ни одному из заказчиков не видоизменяется под него на уровне кода — изменяются только настройки, лежащие в БД. Это круто, ИМХО!

Структура основана на файлах. Но на страницу подгружается ТОЛЬКО то, что нужно в данный момент.

Napolsky 8 авг 2009 в 21:09

надо будет объединиться и по возможности обменяться опытом/нароботками. Может будет что полезное :)
Правда как я понял, в отличие от моей разработки (ориентированной непосредственно на код) у вас нароботки ориентированные нас структуру

13i 8 авг 2009 в 22:32

с другой стороны, сколько я ни читал, все равно до конца вас не понял, ведь:
php файл может занимать сколько угодно места, но он не будет присутствовать на сгенерированной HTML-странице и она может также не содержать того, что не нужно только с помощью фильтров/проверок/условий на выбор.
Так зачем все усложнять? Зачем php код кидать в БД??? Не хотите инклудов — сделайте один большой файл )))
Мой подход к организации считаю более эффективным, т.к. в бекапах будет сохраняться вся структура, стили и дизайн каждого отдельного сайта, а код будет оставаться для всех неизменным.

Napolsky 9 авг 2009 в 06:38

>> php файл может занимать сколько угодно места
Может, если не волнует вопрос производительности :)

>> Не хотите инклудов — сделайте один большой файл
… и пусть парсер лопатит тонны «мертвого» кода :)

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

13i 9 авг 2009 в 10:50

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

вернемся к вашему вопросу:
— а чем вам инклуды не нравятся??? типо много файлов — это плохо???
— с чего вы взяли, что парсер сильно тормозит, лопачя «мертвяк»?
— вы проводили сравнительные тесты между файлами и php-кодом в БД?

ИМХО, чтобы выполнить php из БД, надо его оттуда сначала вызвать с помощью выборки, а это дополнительные запросы к БД! Конечно, если потом всё приправить кешированием…

Fortop 9 авг 2009 в 11:59

Насколько я понял автора, БД тут как зайцу стопсигнал :) У него просто там хранится библиотека кода.

А собирается это все в реальные скрипты/страницы (причем со своими огромными боками, читайте комменты выше), которые уже потом и работают в реальности.

Napolsky 9 авг 2009 в 13:56

то, как влияет мертвый код и инклуды на производительность (в том числе на связке с кешом опкода) будет подробно рассмотрено в статье, которую я планирую опубликовать во вторник.

>>ИМХО, чтобы выполнить php из БД, надо его оттуда сначала вызвать с помощью выборки, а это дополнительные запросы к БД!

вы тоже невнимательно прочитали статью :) К бд при работе страниц мы уже никак не обращаемся

13i 9 авг 2009 в 12:27

Цеплять кирпичики что из файлов, что из БД всё равно накладно (медленно и неэффективно), куда проще и быстрее цеплять необходимые полноценные модули со своими настройками, которые будут хранится в БД, желательно в небольшом количестве четко структурированных таблиц. Или даже один основной мегамодуль-конструктор (также с настройками в БД), как и поступил я (и это ни сколько не отразилось на производительности).

13i 9 авг 2009 в 16:41

Я прочитал статью прежде, чем писать что-либо.

Читаю статью еще раз:

«Для работы движка (после того как сработает кодеген) бд уже не нужна. То есть сайт может работать и при выключенной бд.»
— Поясните это. У меня вообще мозги всмятку. Вы говорите, что весь код в БД, а потом «К бд при работе страниц мы уже никак не обращаемся», а потом я читаю этот кусок в статье… мрак. При помощи чего тогда вы обращаетесь к БД??? И почему она потом будет не нужна?

Для меня ваш скрипт Codegen — это как раз php (или на другом языке) скрипт для генерации страниц, посредством обращения к БД за php кодом и всем остальным (кроме картинок, я надеюсь).

«генерация кода страницы годегеном происходит 1 раз, а не при каждом обращении к странице.»
т.е. все страницы сознаются и хранятся на сервере в качестве HTML. Вы в курсе, что это создает?
— Где-то в 1,8 раз (минимум) больше будет занимать места на хостинге ваш сайт, по сравнению с любым другим.
— А что будет при добавлении комментариев и с другой интерактивностью? Нужно будет организовать обращения форм к страницам! Мне это сейчас кажется трудным…
— А что будет при удалении страницы? Надо не забыть об удалении соответствующей кешированной страницы с сайта!
— В любом случае админка будет выполнена не на основе БД, как я понимаю…

«Время генерации страницы сократилось с 0.25-0.3 до 0.04-0.05 секунды (~600%. Напоминаю, что это без кеша в классике. с кешом цифра будет поменьше)»
— Т.е. вы уже проверили??? А сколько запросов к БД при таком подходе?

Napolsky 9 авг 2009 в 18:11

у нас в бд хранятся маленькие фрагменты кода (функции, методы класса или классы и т д). Из них codegen собирает php код страниц (читайте в самом начале статьи — я специально отметил, что под «код страницы» везде имеется ввиду исполняемый пхп код). Делает он это один раз. Вот в кодегене у нас и происходит коннект к бд и выборка нужных нам кирпичиков для построения страницы. Поэтому никаких html страниц мы нигде не храним конечно же. И все ваши вопросы теперь должны отпасть как я понимаю :)

13i 9 авг 2009 в 18:22

В общем это получается фреймворк по единоразовому сбору php кода CMS. А вы уже думали над архитектурой, админкой, удобством использования? Когда собираетесь начать реализовывать???

Кстати, если интересно, могу показать скриншоты моей админки. Может что поправите, а може и для себя что найдете. -> karta63.ru/works/cms/

Napolsky 9 авг 2009 в 19:24

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

Скриншоты посмотрел. Правда мало что понял :) Единственное за что зацепился глаз, так это время генерации страниц. Видать на автомате ищет ))

13i 9 авг 2009 в 20:45

Не понял фразу «Видать на автомате ищет ))»

успешные реализации уже есть, например:
samarskie-roditeli.ru — максимум посетителей, который был на сайте 2500, но для Движка это не предел, он и 4000 человек за день легко тянет (больше к сожалению не удалось попробовать)
ladysamara.ru
или последний бета-проект — znatnado.ru (кстати очень интересный)

Napolsky 10 авг 2009 в 04:48

я имел в виду «глаз на автомате ищет скорость выполнения» )) А она у вас такая только для админки или похожее и на страницах сайта?

13i 10 авг 2009 в 05:18

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

runcore 10 авг 2009 в 02:41

как и у автора, у меня возникали подобные мысли, что при отработке сайта парсится куча ненужного кода.
но я начал решать проблему несколько с другой стороны )))
а именно. я стал уменьшать код, выкидывая из него все «универсальные» фичи, или то что писалось для использования «на потом».
Действительно, производя рефакторинг с целью «выкинуть все лишнее», удалось значительно уменьшить код компонент, оставив только самое необходимое, попутно упрощая и уменьшая код того что нужно. В итоге классы стали компактными и более прозрачными…

Это я к тому, что достигнуть времени генерации страницы 0.008 сек. удалось решая проблему с другой стороны )
(без кешера и с коннектом к БД). А достигнутое вами время генерации (0.03 сек) это время работы большинства вменяемых фреймворков. Использование памяти у вас, полагаю, конечно будет меньше, это плюс.

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

Napolsky 10 авг 2009 в 04:54

одна поправка насчет времени — некорректно сравнивать время генерации у различных проектов, естественно различающихся по сложности. То есть в том проекте я например теоретически не мог опуститься ниже планки в 0.027, так как такое время занимали запросы к бд при выполнении скрипта.

runcore 10 авг 2009 в 05:42

согласен.
конечно запросы к БД и их кол-во отнимают бОльшую часть времени.
Видите )) вы сами и указываете, что именно тут узкое место и именно его надо оптимизировать в первую очередь или избавляться совсем используя прегенерацию или кеш.

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

но я имел в виду, что время генерации 0,02-0,05 является средним для большинства проектов с которыми мне приходилось работать. И своими и с чужими, некоторые достаточно сложные и нагруженные.
поэтому я и не увидел смысла городить такой огород, ради того чтобы в итоге, получился неплохой, но не выдающийся, прирост производительности и расхода памяти…
потеряв при этом очень много в других аспектах разработки и поддержки…

НЛО прилетело и опубликовало эту надпись здесь

ua1maks 17 авг 2009 в 10:51

+1
автор бы проверил тыщи на три-четыре пользователей
а пока такие статьи можно назвать развлекательными

НЛО прилетело и опубликовало эту надпись здесь

okneigres 2 сен 2009 в 15:10

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий