Comments 26
Всю статью не осилил — постоянно задавал себе вопрос: какие практические выводы/рекомендации по написанию кода из столь подробных деталей следует? Если никаких — то статья бесполезна
-9
В данном контексте статьи, для меня достаточно познавательно было, как же мне ускорить импорт данных из XML.
У меня реализован универсальный класс импорта данных с рекурсивным вызовом метода, который разбирает XML блоки не ограниченной вложенности. На текущий момент, импорт самого большого файла занимает порядка 18 часов. Если применить реализацию разворачивания рекурсии из статьи, то время импорта существенно сократится. По крайней мере я на это очень надеюсь, так как все возможные оптимизации были реализованы (до оптимизации время импорта достигало 32-х часов)
У меня реализован универсальный класс импорта данных с рекурсивным вызовом метода, который разбирает XML блоки не ограниченной вложенности. На текущий момент, импорт самого большого файла занимает порядка 18 часов. Если применить реализацию разворачивания рекурсии из статьи, то время импорта существенно сократится. По крайней мере я на это очень надеюсь, так как все возможные оптимизации были реализованы (до оптимизации время импорта достигало 32-х часов)
0
Сможете написать, когда проверите? Проводили ли профилирование своего кода, чтобы узнать куда уходит время? Может быть проблема вовсе не врекурсии?
+1
Время в основном уходит на работу с БД.
В общем я переписал на работу через __call. Во времени выигрыш не большой, т.е. сейчас импорт занимает 7 часов ± 15 минут. (до "трамплина" уходило 8 часов ± 15 минут) 12% неплохо смотрится, но всё-равно маловато. Так что переписываю на XmlReader. Даже если время импорта останется в тех же пределах, хотя бы на оперативке выиграю. На текущий момент SimpleXML при загрузке файла съедает 3 Гб.
0
Тоже плюсую за отчет. :)
Партите с помощью xml_parser_create()? Какой размер файла?
Партите с помощью xml_parser_create()? Какой размер файла?
0
Читаю с помощью SimpleXML. Файл размером порядка 300+ Мб.
0
Используйте xml_parser_create().
Он на порядок (-ки) быстрее распрасит, и памяти меньше жрет.
Но парсер нужно почти писать самому. :)
При этом в результирующий массив пихаем только то, что реально нужно, а не весь мусор.
Он на порядок (-ки) быстрее распрасит, и памяти меньше жрет.
Но парсер нужно почти писать самому. :)
При этом в результирующий массив пихаем только то, что реально нужно, а не весь мусор.
0
Мдя, у меня XML — 550MB распарсить занимает секунд 40. Ни каких сторонних библиотек. Читаем построчно, выделяем нужные данные. Расход памяти только на создаваемый массив нужных данных (Если они нужны постоянно, а так — использовал-выбросил). Чуть сложнее, но скорость, расход памяти — великолепные. Кстати, очень сильно тормозят вызовы функций, для оптимизации приходится избавляться от них.
0
Переходите на пхп7 и смело используйте рекурсивные __call
0
Ну я то перешел на 7 и причиной тому была не рекурсия. В рекурсии ничего плохого нет и приведенный пример с замыканием мне кажется еще более ресурсозатратным решением. По существу возврат замыкания означает (далее псевдокод):
return new Closure {
public $usedVar1;
public $usedVar2;
public function call()
{
…
}
};
return new Closure {
public $usedVar1;
public $usedVar2;
public function call()
{
…
}
};
0
На PHP7 уже перешёл, а вот с рекурсивными __call… Пока слабо представляю как это реализовать у себя
0
В Linux под стек обычно выделяют 8 Кб
Что?
0
Это все хорошо, но что на счет exception, которые кидаются внутри __call(), ведь они должны содержать реальный стектрейс без оптимизаций и удаления информации о вызове __call(), что на этот счет?
0
Все норм :)
0
Про трамплины познавательно, даже не думал что можно столь универсально оптимизировать хвостовую рекурсию.
**off-topic:** чего только эти императивщики не придумают вместо `@tailrec`. (знаю, что в scala/haskell/kotlin используются подобный метод, просто шутки ради)
**off-topic:** чего только эти императивщики не придумают вместо `@tailrec`. (знаю, что в scala/haskell/kotlin используются подобный метод, просто шутки ради)
0
Большая лекция от разработчика виртуальной машины PHP Дмитрия Стогова из Zend про PHP 7 и перфоманс:
0
Sign up to leave a comment.
Трамплин вызова магических функций в PHP 7