Лучшая производительность с libxml2 или NSXMLParser на iPhone? - PullRequest
19 голосов
/ 05 мая 2009

Мне любопытно, каково ваше решение для высокопроизводительного анализа XML на iPhone, учитывая его ограниченную мощность процессора. Я рассмотрел приложение XML Performance, которое Apple предоставляет в качестве демонстрации, и кажется, что для фида данных (300 песен iTunes), который они анализируют ... libxml2 всегда, кажется, является победителем.

Имея опыт работы с данными размером менее 100 КБ, что вы предпочитаете для оптимальной производительности? В настоящее время я использую TouchXML + libxml2 и смотрю, можно ли оптимизировать скорость синтаксического анализа как есть.

Спасибо за ваш отзыв!

Ответы [ 8 ]

17 голосов
/ 09 мая 2009

Вы всегда можете посмотреть на мою замену NSXMLParser. Он читает данные XML из потока, а не хранит их все в памяти, и передает их по 1 КБ за раз в libxml (где NSXMLParser передает все сразу).

Исходный код доступен на github , а моя рецензия на аспекты памяти в моем блоге .

16 голосов
/ 06 мая 2009

Я обычно находил для больших кусков данных (как пример яблока, на который вы ссылаетесь) libxml2, как правило, быстрее. Для небольших порций данных разница незначительна. Одним из преимуществ, которые мне нравятся в NSXMLParser, является то, что это реализация синтаксического анализатора XML на основе Objective-C, где libxml2 основан на C.

9 голосов
/ 16 мая 2009

libxml2 всегда будет быстрее, чем NSXMLParser по многим причинам, однако, это зависит от вас, что более полезно для вашего проекта.

NSXMLParser, в целом, красивее. Код имеет смысл, как предполагается, с синтаксическим анализатором, и это настоящий класс Какао со всеми соглашениями там. Если удобство и чистый код - ваши главные приоритеты, тогда вам следует придерживаться NSXMLParser.

Хотя NSXMLParser использует libxml2 на бэкэнде, он медленнее из-за основ Objective-C и ахиллесовой пяты Objective-C. При синтаксическом анализе XML вы, по сути, просто делаете много узких циклов снова и снова, ища интересующие вас теги.

В этом и заключается урок - когда в Objective C, находящемся в тесном цикле, когда вы не можете использовать быстрое перечисление объектов, вы видите серьезное снижение производительности. Dispatch / Delegate RespondsToSelector / и другие конструкции языка Objective C дают вам реальный недостаток.

Я не собираюсь вдаваться в рассылку, но суть в том, что всякий раз, когда вы получаете доступ к чему-то вроде этого: "[zomg lolz]" вы передаете сигнатуру метода диспетчеру target-c, чтобы найти цель C -функция для вашей подписи метода Objective-C. Этот процесс поиска, когда выполняется снова и снова, может значительно снизить вашу производительность.

Если вы на iPhone, зайдите на libxml2 и не оглядывайтесь назад - но если у вашей целевой машины есть два процессора и больше оперативной памяти, чем бога, я бы пошел NSXMLParser для упрощения поддержки кода.

5 голосов
/ 11 мая 2009

Я попробовал свои данные (около 600 записей) с помощью приложения для анализа XML, которое предоставляет Apple. Обнаружил, что libxml2 намного быстрее, чем NSXMLParser. Я переключился на libxml2 (хотя я нахожу его более сложным для реализации, чем NSXMLParser, он хорошо подходил моей цели)

Тот же пример, который пробовал с примерно 100 записями, не имеет большой разницы в обеих реализациях.

2 голосов
/ 16 мая 2009

libxml2 всегда будет быстрее, чем NSXMLParser. NSXMLParser предоставляет вам достойный API-интерфейс, основанный на событиях, но он построен поверх libxml2 и также не основан на потоке (например, NSXMLParser передает весь блок данных сразу в libxml2).

Если вы оптимизируете скорость, libxml2 определенно поможет. Однако, если вам нужен API-интерфейс на основе событий obj-c и вас не очень заботит производительность, NSXMLParser - подходящий инструмент для этой работы. И обратите внимание, что NSXMLParser не обязательно медленный, он просто не такой быстрый, как libxml2.

1 голос
/ 28 августа 2009

Если вы хотите использовать libxml2 с фронтальной частью Objective-C, взгляните на этот полезный набор функций оболочки .

Вы отправляете запрос Xpath к своему объекту XML-документа и возвращаете объекты класса Foundation: NSArray, NSString и NSDictionary.

Эти функции помогают объединить скорость libxml2 с удобочитаемостью кода Objective-C.

0 голосов
/ 15 мая 2009

Я использовал Objective-Xml. Это еще одна капля в замен NSXMLParser. Это дало мне 15-секундное улучшение для файла, который занимал более 1 минуты для анализа. Хотя все еще слишком медленно.

0 голосов
/ 15 мая 2009

libxml2 быстрее, чем NSXMLParser, а также более гибок. Он также имеет очень небольшую (но заметную) утечку памяти с интерфейсом xmlReader (мой любимый интерфейс набора) в SDK, выпущенном с iPhone OS 2.2.1. Детали, встроенные в http://inessential.com/2009/02/25/moving_to_libxml2_sax2. У других интерфейсов в libxml2 такой проблемы нет - как и у моего любимого.

С функциональной точки зрения вы не заметите разницу с относительно небольшими объемами XML, но если вы обнаружите, что просматриваете большой набор, передаваемый в синтаксический анализатор, это станет заметным.

Как уже упоминалось в zPesk, при работе с меньшими объемами данных вы можете с уверенностью использовать прямую работу с Objective-C более выгодно, чем небольшую производительность, которую вы получаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...