Дамп массива в PHP-код

[Xeon303]

Дамп массива в PHP-код

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

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

p.s. Кто-нибудь в курсе, по какой причине угробили http://ru2.php.net/manual/ru/ (русскую версию)

 

[Gremboloid]

http://ru2.php.net/manual/en/function.var-export.php ?

 

[Adelf]

Перед тем как делать, думаю, стоит посмотреть насколько хуже(и хуже ли) (un)serialize по сравнению с var_export/include. Многие юзают для этих целей serialize и не парятся. Ибо она быстро и хорошо делает свое дело.

 

[Фанат]

охохо. очередной охотник за быстродействием.

 

[Xeon303]

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

Сам-то я вообще разлюбил эти "шаблонизаторы", т.к. написать <?=$var?> не особо сложнее, чем {$var}. Ах, да, о чем это я?)

 

[DiMA]

инклюд с пхп массивом будет быстрее и целиком закеширован

а команду ансериалайз придется исполнять каждый раз

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

 

[Xeon303]

Gremboloid
да, кстати, спасибо. То что надо.

 

[Adelf]

Я кстати сравнить решил. Понимаю что при использовании всяких eAccelerator и т.д. результаты будут другими но все же:

массив 10000 элементов.

Первый вариант:
значения: $arr['name'.$i] = 1.0/$i; // дробные числа. У serialize там получаются значения в 20-30 знаков после запятой. var_export жадничает(слегка теряет точность).
Время доставания результата:

var - ~0.03 сек
ser - ~0.06 сек

Второй вариант:
значения: $arr['name'.$i] = $i; // Целые числа. Все просто.
Время доставания результата:

var - ~0.024 сек
ser - ~0.004 сек

З.Ы. Не усложняй

 

[Xeon303]

Adelf
хочешь сказать во втором случае, unserialize работает быстрее инклюда? Или ты про сохранение говоришь? Сохранить - так это мне всё равно, хоть 10 секунд. Данные меняться будут раз в 2-3 дня.

 

[Adelf]

Время доставания результата: . Время генерации я не глядел.

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

Если ты используешь какой-нибудь оптимизатор на сервере, то скорее всего вариант с var_export/include все равно будет быстрее. Но не экономь на спичках.

 

[Gremboloid]

Так Adelf. Включи мозг.

а число сообщений набирай в другом месте.

 

[Adelf]

Число сообщений - не совсем то что мне нужно от жизни.

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

Уже не совсем в тему: Тесты с eAccelerator - include быстрее, чем unserialize из файла примерно в полтора раза.

 

[Gremboloid]

скажи что ты выберешь

include 'conf.php';

в котором уже прописан массив $conf

или

$conf = unserialize(file_get_contents('conf.txt'));

conf.txt содержит пригодное для хранения представление переменной, созданое с помощью serialize

при условии что данные меняются очень редко?

 

[Adelf]

unserialize.

1. Логика. Мы загружаем какие-то данные. Почему для загрузки данных я должен выполнить код?

2. Exceptions. При возникновении каких-то проблем с генерацией файла - unserialize ругнется и ничего не вернет. При include может быть Fatal Error.

3. Безопасность. Поскольку в файл conf.php правами разрешено писать, ктото(но не наш скрипт) может туда что-то записать. А мы выполним этот код.

Да у меня мозг еще не включен. Но мне достаточно этих аргументов. Ради прибавки в скорости загрузки закешированного массива в 1,5 раза я бы не стал так делать. Понимаю, если бы скорость была раз в 10 больше и это было бы критично...

 

[dimagolov]

1. потому что код может закешироваться
2. даже при автоматической генерации файла ничего не мешает проверить его работоспособность тем же генерирующим скриптом (сделать запрос который вызовет его подключение и посмотреть код ответа)
3. единственный нюанс, что файл будет с правами записи тому пользователю, от которого запущен web-сервер. но только тогда, когда надо генерить файл из-под вызываемого по http скрипта (если запускать генерилку из шела то права могут быть какими угодно, не связанными с web-сервером). даже если и так, то в большинстве случаев эти права там будут и так, так как сервер будет запущен от владельца аккаунта и запретить ему писать в себя не получится

 

[Gremboloid]

упал под стол

 

[Adelf]

3. Я не знаток конечн, но помоему весьма разумно запретить web-юзеру писать туда, где лежат файлы php(а зачем ему туда писать то?).

2. Проверка довольно сложная получается.

З.Ы. Вы тока не подумайте что я вообще не приемлю вариант с include. Он очень хорош.

 

[Фанат]

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