Насчет использования памяти я реально заморачивался только один раз. Когда делал "демона", для него это было очень важно.
в общем по логике из топика ссылкой выше, после экспериментов получается
нужно выставлять в настройках php лимит памяти и все скрипты стараться держать в его пределе мегабайтов 5-10 желательно....
нагрузка на сервер тем более с тяжелыми запросами должна быть лимитирована и контролироваться, допустим демонами
большие и тяжелые процессы необходимо рубить
и все равно даже математически высчитанные расходы и затраты не помогут, сервак может упасть, память утечь
Полная Версия: нагрузка на операционку
hurt3, еще раз, зачем свой велосипед, парсер который я дал, умеет все это делать. Определять начала массива, объекта, читаемый ключ и значение.
Что бы установить эту библиотеку , нужен композер.
https://getcomposer.org/
Когда поставишь композер, можешь указать библиотеку, он загрузит с пакеджиста https://packagist.org/packages/im0rtality/j...streamingparser
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Что бы установить эту библиотеку , нужен композер.
https://getcomposer.org/
Когда поставишь композер, можешь указать библиотеку, он загрузит с пакеджиста https://packagist.org/packages/im0rtality/j...streamingparser
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
интересная читалка, а поэтапно как читать им?
или вообще читать, и еще он ведь целиком файл получает?
или вообще читать, и еще он ведь целиком файл получает?
Santehnick
я наврено страшно туплю, но как ты обращаешься к защищенному методу?
я понимаю что это наглость, но
Можно реализацию в студию, как поэтапно вывести дочерние элементы массива?
я наврено страшно туплю, но как ты обращаешься к защищенному методу?
я понимаю что это наглость, но
Можно реализацию в студию, как поэтапно вывести дочерние элементы массива?
hurt3
потоковых парсеров валом на самом деле. Есть и более удобные в использовании варианты, например этот
https://github.com/pcrov/JsonReader
примеры использования тут
P.S. он требует PHP7.
потоковых парсеров валом на самом деле. Есть и более удобные в использовании варианты, например этот
https://github.com/pcrov/JsonReader
примеры использования тут
P.S. он требует PHP7.
| Цитата (hurt3 @ 8.01.2018 - 13:38) |
| Можно реализацию в студию, как поэтапно вывести дочерние элементы массива? |
извиняй, но вряд ли кто-то поможет тебе с реализацией. Деньги ты получаешь, а не мы. Мы тебе дали кучу инструментов решающие твою задачу. Инструменты рабочие, твое дело научиться ими пользоваться и решить поставленную задачу.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
пока форум висел вчера свой реализовал, но примеры выше помогли
chee ничего да это и правильно
понять бы эти инструменты это вообще могут сделать или их перепиливать нужно?
Да перепиливать видимо все равно придется
твой целиком читает строку, и поэтому полностью забрал файл.
а вот у киллера
killer8080
странно это но похоже происходит побайтовое чтение строки ммм
chee ничего да это и правильно
понять бы эти инструменты это вообще могут сделать или их перепиливать нужно?
Да перепиливать видимо все равно придется
твой целиком читает строку, и поэтому полностью забрал файл.
а вот у киллера
killer8080
странно это но похоже происходит побайтовое чтение строки ммм
hurt3, при возникновении проблем с обработкой данных, в первую очередь следует обратить пристальное внимание на их структуру. Насколько правильно она подобрана под задачу.
И кстати, ничего странного в побайтовом чтении, для потоковых парсеров, я не нахожу. Очень правильный подход, который позволяет реализовать сильно упрощенный алгоритм скобочной последовательности, для разделения объектов (или порций, если угодно). По какому признаку вопрос отдельный, и намного более сложный. Более того, он может быть (и чаще всего) сильно связан с алгоритмами обработки получаемых данных. Необходимая целостность юнита данных для итерации, особенно при условии сильной вложенности. Это к вопросу эффективности потоковых парсеров "универсальных" форматов.
Но, повторюсь, проблемы с обработкой чаще всего указывают на неправильно подобранный формат/структуру данных.
А вообще, то что ты пытаешься решить, подпадает под анализ Big O (и последующую оптимизацию), который, в свою очередь, тянет за собой довольно серьезные теоретические познания по структурам данных, принципам хранения и алгоритмам обработки.
И кстати, ничего странного в побайтовом чтении, для потоковых парсеров, я не нахожу. Очень правильный подход, который позволяет реализовать сильно упрощенный алгоритм скобочной последовательности, для разделения объектов (или порций, если угодно). По какому признаку вопрос отдельный, и намного более сложный. Более того, он может быть (и чаще всего) сильно связан с алгоритмами обработки получаемых данных. Необходимая целостность юнита данных для итерации, особенно при условии сильной вложенности. Это к вопросу эффективности потоковых парсеров "универсальных" форматов.
Но, повторюсь, проблемы с обработкой чаще всего указывают на неправильно подобранный формат/структуру данных.
А вообще, то что ты пытаешься решить, подпадает под анализ Big O (и последующую оптимизацию), который, в свою очередь, тянет за собой довольно серьезные теоретические познания по структурам данных, принципам хранения и алгоритмам обработки.
| Цитата (sergeiss @ 6.01.2018 - 04:13) |
| Ты считаешь, что сможешь сделать этот разборе более эффективно, чем это сделано в ПХП??? |
В случае неполной поддержки формата? Разумеется!
тыц
Вообще, в PHP реализуются очень обобщенные алгоритмы, например той же сортировки, но не только, к сожалению. Поэтому, собственные "прицельные" реализации как правило во много раз эффективнее. Даже несмотря на то, что выполнены на ЯП более высокого уровня.
виноват побайтовый разбор не чтение
И кстати, ничего странного в побайтовом чтении, для потоковых парсеров, я не нахожу. Очень правильный подход, который позволяет реализовать сильно упрощенный алгоритм скобочной последовательности, для разделения объектов (или порций, если угодно).
а скорость, каждый символ проверить?
я explod ом порубил на основе " склеил значения если на стыке \"
два типа значений в массиве получилось
операторы- {}[]:, и данные- null false true строки в кавычках и числа
если в операторе что-то лишнее значит либо начался ключ/значение -пересборка массива
данные должны приходить в utf-8 так что думаю проблем с кодировкой не возникнет
да может и велосипед но написано под задачу - разделять дочерние объекты второго уровня вложенности
а библиотеки на интересные мысли навели
если я из виду что-то упускаю просьба подсказать
ну и я так понимаю, что подобными решениями лучше большие массивы соединять, делить и перерабатывать - указал значение функции класс отработал, легче чем дробить массивы
И кстати, ничего странного в побайтовом чтении, для потоковых парсеров, я не нахожу. Очень правильный подход, который позволяет реализовать сильно упрощенный алгоритм скобочной последовательности, для разделения объектов (или порций, если угодно).
а скорость, каждый символ проверить?
я explod ом порубил на основе " склеил значения если на стыке \"
два типа значений в массиве получилось
операторы- {}[]:, и данные- null false true строки в кавычках и числа
если в операторе что-то лишнее значит либо начался ключ/значение -пересборка массива
данные должны приходить в utf-8 так что думаю проблем с кодировкой не возникнет
да может и велосипед но написано под задачу - разделять дочерние объекты второго уровня вложенности
а библиотеки на интересные мысли навели
если я из виду что-то упускаю просьба подсказать
ну и я так понимаю, что подобными решениями лучше большие массивы соединять, делить и перерабатывать - указал значение функции класс отработал, легче чем дробить массивы
Здесь расположена полная версия этой страницы.