Comments 38
А как на счет использовать бд?
И как вы предлагаете использовать БД?
вероятно, камрад предлагает сверхбыстро гнать данные в таблицы через load infile, и нагружать поиском и обработкой уже бд
я лично недопонял задачи: вы упёрлись в ограничение быстродействия фс на выборку и чтение файлов? вы считываете данные из файлов в память для последующей обработки?
я лично недопонял задачи: вы упёрлись в ограничение быстродействия фс на выборку и чтение файлов? вы считываете данные из файлов в память для последующей обработки?
У меня статический массив 200 на 200. (который изменяется в очень крайнем случае)
Чтобы этот массив распаковать в переменную — требуется процессорное время.
0.023 секунды — одна расспаковка такого огромного массива в переменную. Поиск и обработка средствами БД не подходит совсем — потому что в задаче используется пересеченный поиск по массиву.
Чтобы этот массив распаковать в переменную — требуется процессорное время.
0.023 секунды — одна расспаковка такого огромного массива в переменную. Поиск и обработка средствами БД не подходит совсем — потому что в задаче используется пересеченный поиск по массиву.
чур меня, чур! пхп гнётся уже на 1к элементов, а тут 40к!
может, попробовать что-нибудь прогрессивное типа XQuery? или что-нибудь хорошо забытое, вроде алгоритмов работы с матрицами и разряжёнными матрицами, в частности?
может, попробовать что-нибудь прогрессивное типа XQuery? или что-нибудь хорошо забытое, вроде алгоритмов работы с матрицами и разряжёнными матрицами, в частности?
кстати, если вы не храните ссылки на разнообразные данные в этом массиве, то в своем случае можете попробовать свой массив перевести в непрерывный разделяемый блок памяти (это которые system v shared memory ), просто проецировать его в адресное пространство php и арифметическими действиями с распаковкой считывать данные.
Конечно, снизится скорость считывания из массива, но может быть вас устроит общий результат.
Конечно, снизится скорость считывания из массива, но может быть вас устроит общий результат.
да не в фс тут дело а в распаковке данных
хоть в память положите, а как вы транслировать то будите?
ru.php.net/manual/ru/function.shmop-write.php
хоть в память положите, а как вы транслировать то будите?
ru.php.net/manual/ru/function.shmop-write.php
Функция return_path() лишняя. Можно так:
file_put_contents(PREDEFINED_PATH,"<?php return '.var_export($data,TRUE).';'); ... $path=include PREDEFINED_PATH;
Можно и так. В принципе смысл от этого не меняется :)
Еще как меняется, в этом случае Вы не плодите лишнюю глобальную функцию, данные можно подтягивать не заботясь о том, какие Вы перед этим подтягивали и сколько раз.
Плюс рекомендую пользоваться $path = include(some_path); (вызов со скобками, так корректнее — как бы функция вернет значение), хотя вот это уже точно не принципиально )
Плюс рекомендую пользоваться $path = include(some_path); (вызов со скобками, так корректнее — как бы функция вернет значение), хотя вот это уже точно не принципиально )
А вообще — при 40К элементов возможно есть смысл как-то данные разбить или переформировать. Чтобы обрабатывать кусками.
Еще советую посмотреть в сторону APC — он умеет кешировать переменные, потестируйте. В связке с eAccelerator должно хорошо работать.
Еще советую посмотреть в сторону APC — он умеет кешировать переменные, потестируйте. В связке с eAccelerator должно хорошо работать.
Хороший совет. Спасибо.
Век учись… eAccelerator имеет оказывается свой API… А я вилосипед придумывал :)
В результате практически мгновенно можно получить данные, пряма из памяти горячими:
(массив 1кб)
eaccelerator_get — 0.00004 sec
apc_get — 0.00816 sec
В результате практически мгновенно можно получить данные, пряма из памяти горячими:
(массив 1кб)
eaccelerator_get — 0.00004 sec
apc_get — 0.00816 sec
И снова не прав я… accelerator_get хранит ссылку на объект :)
apc_get работает со скоростью unserialize
Занятно, не ожидал )
Сейчас провёл ещё один интересный тест:
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). Есть смысл использования только при больших объемах.
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). Есть смысл использования только при больших объемах.
Эммм… а как получается, что
unserialize($string) — 0.54
unserialize(file_get_content($file)) — 0.53
Какой-то неадекват, Вам не кажется? Ведь во втором случае присутствует операция с файлом, и это всяко дольше, чем со строкой, которая уже есть. А время меньшее.
unserialize($string) — 0.54
unserialize(file_get_content($file)) — 0.53
Какой-то неадекват, Вам не кажется? Ведь во втором случае присутствует операция с файлом, и это всяко дольше, чем со строкой, которая уже есть. А время меньшее.
Да, я согласен. В первом случае 0.541, во втором 0.539 ;)… 1% ошибки вычислений вкрался…
Ну так все равно второй быстрее получается :) Результат противоречит моей логике… Не может файл дергаться быстрее, чем PHP со своей строкой работает… Просто файл с точки зрения РНР — это в итоге та же строка.
Я говорю о том, что процессор — многозадачная машина и в этом случае обязательно будет набегать ошибка.
Работа с файлом не быстрее работы с памятью — а медленее, потому что необходимо сделать несколько операций:
1) Запуск функции
2) Проверка кеша (если файл закеширован, что в нашем случае и происходит)
3) Возврат из кеша файла.
Просто параллельно выполнялось какое-то действие, (кто-то решил загрузить страницу на сервере). Значения, которые я тут предоставил на самом деле ±0.01 сек.
Работа с файлом не быстрее работы с памятью — а медленее, потому что необходимо сделать несколько операций:
1) Запуск функции
2) Проверка кеша (если файл закеширован, что в нашем случае и происходит)
3) Возврат из кеша файла.
Просто параллельно выполнялось какое-то действие, (кто-то решил загрузить страницу на сервере). Значения, которые я тут предоставил на самом деле ±0.01 сек.
Тут скрыта еще одна проблема: потребление памяти. При таких объемах каждый экземпляр интерпретатора php создает свою копию массива. Есть целый класс движков, которые используют сходное кеширование. Из-за этого, в некоторых ситуациях получаем просто невероятный перерасход памяти. Очень бы помогла реализация уже собранных и упакованных в сплошной блок разделяемой памяти статичных массивов, но я ее не нашел.
м.б. memcache?
хм… результаты json_encode неплохи в целом…
уже даже то что json не передаёт информацию о размере данных а только их значения позволяет использовать его для кеширования и снизить размер кеш-файлов… протестив его дальше заметил не очень приятную особенность, а именно вырезание русских строк…
пример:
$arr = array ( '1' => 'хабрахабр' );
echo json_encode( $arr );
на выходе получаем {«1»:""}…
уже даже то что json не передаёт информацию о размере данных а только их значения позволяет использовать его для кеширования и снизить размер кеш-файлов… протестив его дальше заметил не очень приятную особенность, а именно вырезание русских строк…
пример:
$arr = array ( '1' => 'хабрахабр' );
echo json_encode( $arr );
на выходе получаем {«1»:""}…
Оптимизировать надо не код, уменьшая загрузку с 0.08 до 0.02, а архитектуру
Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде "
Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде
Попробуйте www.softcoder.ru/habraeditor/ (и обязательно предпросмотр перед постом)
Кстати, замечено по многочисленным тестам, что загрузка сохранённого в файл в виде php return массива при включенном APC (и соответственно закэшированном скомпилированном файле, т.е. файл уже находится в памяти) работает быстрее, чем загрузка тех же самых данных при помощи apc_get.
Похоже это связано с тем, что всё равно при apc_get возможно проходит какая-то десериализация.
Похоже это связано с тем, что всё равно при apc_get возможно проходит какая-то десериализация.
Sign up to leave a comment.
Оптимизация загрузки статических данных