Оптимизация загрузки статических данных

[Nc_Soft]

А как на счет использовать бд?

[l2k]

И как вы предлагаете использовать БД?

[habraname]

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

я лично недопонял задачи: вы упёрлись в ограничение быстродействия фс на выборку и чтение файлов? вы считываете данные из файлов в память для последующей обработки?

[l2k]

У меня статический массив 200 на 200. (который изменяется в очень крайнем случае)
Чтобы этот массив распаковать в переменную — требуется процессорное время.

0.023 секунды — одна расспаковка такого огромного массива в переменную. Поиск и обработка средствами БД не подходит совсем — потому что в задаче используется пересеченный поиск по массиву.

[habraname]

чур меня, чур! пхп гнётся уже на 1к элементов, а тут 40к!
может, попробовать что-нибудь прогрессивное типа XQuery? или что-нибудь хорошо забытое, вроде алгоритмов работы с матрицами и разряжёнными матрицами, в частности?

[l2k]

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

[pwlnw]

кстати, если вы не храните ссылки на разнообразные данные в этом массиве, то в своем случае можете попробовать свой массив перевести в непрерывный разделяемый блок памяти (это которые system v shared memory ), просто проецировать его в адресное пространство php и арифметическими действиями с распаковкой считывать данные.
Конечно, снизится скорость считывания из массива, но может быть вас устроит общий результат.

[developer]

да не в фс тут дело а в распаковке данных
хоть в память положите, а как вы транслировать то будите?
ru.php.net/manual/ru/function.shmop-write.php

[pwlnw]

Можно попытаться копированием значений упаковать массив в непрерывный блок. Там будут ссылки на значения внутри того же блока. Без понимания внутренних механизмов работы php мне сложно оценить успешность.
Вы видите какие-нибудь проблемы?

[Roxis]

Функция return_path() лишняя. Можно так:

file_put_contents(PREDEFINED_PATH,"<?php return '.var_export($data,TRUE).';');
...
$path=include PREDEFINED_PATH;

[l2k]

Можно и так. В принципе смысл от этого не меняется :)

[dfuse]

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

Плюс рекомендую пользоваться $path = include(some_path); (вызов со скобками, так корректнее — как бы функция вернет значение), хотя вот это уже точно не принципиально )

[dfuse]

А вообще — при 40К элементов возможно есть смысл как-то данные разбить или переформировать. Чтобы обрабатывать кусками.

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

[l2k]

Хороший совет. Спасибо.

[l2k]

Век учись… eAccelerator имеет оказывается свой API… А я вилосипед придумывал :)

В результате практически мгновенно можно получить данные, пряма из памяти горячими:
(массив 1кб)
eaccelerator_get — 0.00004 sec
apc_get — 0.00816 sec

[l2k]

И снова не прав я… accelerator_get хранит ссылку на объект :)

[l2k]

apc_get работает со скоростью unserialize

[dfuse]

Занятно, не ожидал )

[l2k]

Сейчас провёл ещё один интересный тест:
unserialize($string) — 0.54
unserialize(accelerator_get()) — 0.56
unserialize(file_get_content($file)) — 0.53
apc_get() — 0.46

Вывод — apc_get быстрее на 10%, чем unserialize :).
То есть, при операциях в 10 ms (0.001 сек) не имеет смысла его использовать. (выйгрыш по сравнению с unserialize будет 1ms). Есть смысл использования только при больших объемах.

[dfuse]

Эммм… а как получается, что

unserialize($string) — 0.54
unserialize(file_get_content($file)) — 0.53

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

[l2k]

Да, я согласен. В первом случае 0.541, во втором 0.539 ;)… 1% ошибки вычислений вкрался…

[dfuse]

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

[l2k]

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

Работа с файлом не быстрее работы с памятью — а медленее, потому что необходимо сделать несколько операций:
1) Запуск функции
2) Проверка кеша (если файл закеширован, что в нашем случае и происходит)
3) Возврат из кеша файла.

Просто параллельно выполнялось какое-то действие, (кто-то решил загрузить страницу на сервере). Значения, которые я тут предоставил на самом деле ±0.01 сек.

[dfuse]

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

[l2k]

Времени особо небыло ;)

[pwlnw]

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

[VladimirAndreev]

м.б. memcache?

[pwlnw]

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

Нет. Там та же самая десереализация да и еще и перекачка данных по tcp-стеку.

[nickon]

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

$arr = array ( '1' => 'хабрахабр' );
echo json_encode( $arr );

на выходе получаем {«1»:""}…

[l2k]

UTF-8 вас спасёт :).
Обязательно перед кодированием необходимо пребобразовывать строку в UTF-8.

Чтобы не мучатся, у себя я уже давно использую UTF-8, как основное, работая с ним прямо в Базе данных.

[nickon]

UTF всегда спасает :) также его юзаю…
но в данном случае выходит что использовать UTF-8 накладно, т.к. при выполнении вышеуказанного примера получаем:

{«1»:"\u0445\u0430\u0431\u0440\u0430\u0445\u0430\u0431\u0440"}

т.е. 62 байта из 17, что в следствии даст увеличение размера кеша.

[l2k]

p.s. охрененная фотография :)

[highw]

Оптимизировать надо не код, уменьшая загрузку с 0.08 до 0.02, а архитектуру

[l2k]

Задачи бывают совершенно разные

[DjOnline]

Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде "

[DjOnline]

Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде

[l2k]

Попробуйте www.softcoder.ru/habraeditor/ (и обязательно предпросмотр перед постом)

[DjOnline]

Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде php return массива при включенном APC (и соответственно закэшированном скомпилированном файле, т.е. файл уже находится в памяти) работает быстрее, чем загрузка тех же самых данных при помощи apc_get.
Похоже это связано с тем, что всё равно при apc_get возможно проходит какая-то десериализация.