Comments 21
Спасибо, интересно. Но у вас все типы относительно простые - массивы и строки. Для полноты кратины не хватает кодирования/декодирования объектов (экземпляров классов).
Вот здесь товарищ великолепно высказался по этому поводу: http://habrahabr.ru/blog/php/47851.html#…
я что-то не совсем понимаю необходимость данного теста, если нужно передать массив/объект в JS через ajax — разве кто-то будет сомневаться чем это сделать?
точно также, если мне на память нужно сохранить массив в базе, но не предполагается поиск по нему, а планируется его полная выборка в будущем или передача данных через url с кодирование base64, то чем вы будете пользоваться?
вы молодец, потратили время на создание тестов, но как-то нерационально: описали очевидные вещи, был бы успех если бы статья кончилась: долой классические прототипы мышления, быстрее оказывается ТАК, а пока...
точно также, если мне на память нужно сохранить массив в базе, но не предполагается поиск по нему, а планируется его полная выборка в будущем или передача данных через url с кодирование base64, то чем вы будете пользоваться?
вы молодец, потратили время на создание тестов, но как-то нерационально: описали очевидные вещи, был бы успех если бы статья кончилась: долой классические прототипы мышления, быстрее оказывается ТАК, а пока...
а зависит ли скорость json_decode от значения его второго параметра?
ибо в умолчательном варианте вы, вообще-то, после decode получаете во-первых совсем не то, что закодировали, а во-вторых, насколько я понимаю, создание экземпляра объекта должно быть более тяжелой операцией, нежели создание массива.
ибо в умолчательном варианте вы, вообще-то, после decode получаете во-первых совсем не то, что закодировали, а во-вторых, насколько я понимаю, создание экземпляра объекта должно быть более тяжелой операцией, нежели создание массива.
А Вы случайно не британский учёный?
json_decode
This function will return false if the JSON encoded data is deeper than 127 elements.
Недавно стакнулся с данной ситуацией, так что не всегда удобно использовать при больших объемов данных. Или использовать средства для работы с json не входящие в основную сборку php
This function will return false if the JSON encoded data is deeper than 127 elements.
Недавно стакнулся с данной ситуацией, так что не всегда удобно использовать при больших объемов данных. Или использовать средства для работы с json не входящие в основную сборку php
По моему, эта тема не стоит того, чтобы ее выносить для обсуждения (даже для первого поста). Возникший вопрос решается на коленке за пару минут, а выбор способа упаковки обусловлен в большей степени целями, но никак не скоростью.
Не стоит заниматься преждевременной оптимизацией, это зло. Оптимизировать нужно тогда, когда у вас появятся проблемы с производительностью.
Не стоит заниматься преждевременной оптимизацией, это зло. Оптимизировать нужно тогда, когда у вас появятся проблемы с производительностью.
casey, вы понимает различие между JSON и сериализацией? и когда что применяется?
Да, здесь я разбирал применение одного и другого для хранения абстрактного массива данных.
вы видели что получается на выходе json_decode в том виде, в котором он у вас использован в коде теста?
Мне кажется, вы всё-же не понимаете зачем и для чего сделан json.
hint: он не подходит для хранения абстрактного php-шного массива данных.
Мне кажется, вы всё-же не понимаете зачем и для чего сделан json.
hint: он не подходит для хранения абстрактного php-шного массива данных.
Спасибо за дельный комментарий. Если я правильно понял, Вы имеете в виду то, что json_encode в php работает только с латиницей и utf-8?
нет, я имел ввиду что две следующие строчки дадут разный результат и, как следствие, тест, который это не учитывает, не является корректным:
print_r (json_decode (json_encode(array ('one'=>'two'))); // будет инстанс stdClass с пропертёй one которая равна строке 'two'
print_r (unserialize (serialize(array ('one'=>'two'))); // выдаст именно то, что засовывали.
Это важно как с точки зрения корректности теста, так и с точки зрения быстродействия, т.к. манипуляции с объектами в пхп затратнее, чем манипуляции с массивами.
Еще это важно с точки зрения доказательства того факта, что вы делаете абстрактные тесты, явно ниразу по-настоящему не использовав предмет тестирования в реальных задачах, но это уже мелочи (-:
Т.е. в вашем тесте надо как минимум выставить второй параметр json_decode() в true.
Впрочем, это не отменяет того факта, что json не является средством сериализации произвольных данных.
print_r (json_decode (json_encode(array ('one'=>'two'))); // будет инстанс stdClass с пропертёй one которая равна строке 'two'
print_r (unserialize (serialize(array ('one'=>'two'))); // выдаст именно то, что засовывали.
Это важно как с точки зрения корректности теста, так и с точки зрения быстродействия, т.к. манипуляции с объектами в пхп затратнее, чем манипуляции с массивами.
Еще это важно с точки зрения доказательства того факта, что вы делаете абстрактные тесты, явно ниразу по-настоящему не использовав предмет тестирования в реальных задачах, но это уже мелочи (-:
Т.е. в вашем тесте надо как минимум выставить второй параметр json_decode() в true.
Впрочем, это не отменяет того факта, что json не является средством сериализации произвольных данных.
Кстати, в этом вопросе "что когда применяется" есть и варианты. Например, для передачи данных в бекенде использовать между различными модулями системы в определенных целях JSON или сериализацию с распаковкой/упаковкой через какой-нибудь интерфейс (например для унифицированной архитектуры ПО). При этом JSON легко отдавать фронтенду без дополнительной обработки, а сериализированные объекты еще придется дополнительно обрабатывать для этого. И такой тест интересен перед проектированием самой системы, чтобы знать какие грабли лучше.
что для вас (front/back)end?
Честно говоря слабо могу себе представить ситуацию, когда переданные из другого модуля сериализованные данные должны быть сразу отправлены во фронтэнд, обычно такие данные используются для того чтобы изменить поведение конечного модуля, а их для этого соот-но нужно десериализовать.
По моему, если необходимо передать данные на фронтэнд в необработанном виде то JSON значительно удобнее, он унифицирован, и имеет реализации для некоторых JS фреймворков (пр. MooTools) в отличии от сериализации, по крайней мере когда мне понадобилось передавать данные с сервера на клиент, для их последующей обработки и представления на клиенте в ввиде HTML, я воспользовался именно JSON'ом как прослойкой между PHP и MooTools, и не пожалел, получилось удобно, универсально и не привязано к конкретному отображению + немного разгрузил этим бекэнд от лишних преобразований + удобно кэшировать — один раз «отгенерировал» JSON-строку, положил в файл, а потом подгружать статичный файл.
Имеется еще желание попробовать для аналогичных целей применить «Protocol Buffers» от Google, если у кого то есть опыт его применения в связке с PHP было бы интересно послушать.
Имеется еще желание попробовать для аналогичных целей применить «Protocol Buffers» от Google, если у кого то есть опыт его применения в связке с PHP было бы интересно послушать.
Сейчас пишу программу…
провёл тест…
На огромных массивах с 2х-кратной вложенностью — unserialize выигрывает по скорости в 2 раза у json_decode, хотя последний занимает в 1.5 меньше пространства.
провёл тест…
На огромных массивах с 2х-кратной вложенностью — unserialize выигрывает по скорости в 2 раза у json_decode, хотя последний занимает в 1.5 меньше пространства.
Sign up to leave a comment.
Производительность кодирования и декодирования serialize и json — часть вторая