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