Лучшая производительность с libxml2 или NSXMLParser на iPhone?

Обновление NPM сделало это!

sudo npm install -g npm@latest
19
задан 5 May 2009 в 18:28
поделиться

8 ответов

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

16
ответ дан 30 November 2019 в 02:39
поделиться

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

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

17
ответ дан 30 November 2019 в 02:39
поделиться

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

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

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

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

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

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

Dispatch / Delegate RespondsToSelector / и другие конструкции базового языка Objective C создают здесь реальный недостаток.

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

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

Dispatch / Delegate RespondsToSelector / и другие конструкции базового языка Objective C создают здесь реальный недостаток.

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

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

повторная передача сигнатуры метода диспетчеру Objective-C для поиска целевой C-функции для вашей сигнатуры метода Objective-C. Этот процесс поиска, выполняемый снова и снова, может значительно снизить вашу производительность.

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

повторная передача сигнатуры метода диспетчеру Objective-C для поиска целевой C-функции для вашей сигнатуры метода Objective-C. Этот процесс поиска, выполняемый снова и снова, может значительно снизить вашу производительность.

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

9
ответ дан 30 November 2019 в 02:39
поделиться

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

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

2
ответ дан 30 November 2019 в 02:39
поделиться

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

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

5
ответ дан 30 November 2019 в 02:39
поделиться

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

0
ответ дан 30 November 2019 в 02:39
поделиться

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

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

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

0
ответ дан 30 November 2019 в 02:39
поделиться

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

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

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

1
ответ дан 30 November 2019 в 02:39
поделиться