framework - ¿Mejor rendimiento con libxml2 o NSXMLParser en el iPhone?
swift ios documentation (8)
En general, he encontrado que para grandes porciones de datos (como el ejemplo de Apple al que hace referencia), libxml2 tiende a ser más rápido. Para trozos más pequeños de datos, la diferencia es insignificante. Una de las ventajas que me gusta de NSXMLParser es que es una implementación basada en Objective-C de un analizador XML donde libxml2 está basado en C.
Tengo curiosidad por saber cuál es su solución para el análisis XML de alto rendimiento en el iPhone, dada su limitada capacidad de CPU. He revisado la aplicación de rendimiento XML que Apple ofrece como una demostración, y parece que para la fuente de datos (300 canciones de iTunes) que están analizando ... libxml2 siempre parece ser el ganador principal.
Con su experiencia en el manejo de datos que son <100Kb, ¿qué prefiere para un rendimiento óptimo? Actualmente estoy usando TouchXML + libxml2 y estoy buscando para ver si es posible optimizar las velocidades de análisis como están.
Gracias por sus comentarios!
He utilizado Objective-Xml. Esta es otra caída en el reemplazo de NSXMLParser. Me dio una mejora de 15 segundos en un archivo que tardaba más de 1 minuto en analizar. Sin embargo, sigue siendo demasiado lento.
Probé mis datos (alrededor de 600 registros) utilizando la aplicación de análisis XML que proporciona Apple. Encontró que el libxml2 es mucho más rápido que NSXMLParser. Cambié a libxml2 (aunque me parece un poco más complejo de implementar que NSXMLParser, se adaptó bien a mi propósito)
El mismo ejemplo probado con unos 100 registros no tiene mucha diferencia en ambas implementaciones.
Siempre puedes echar un vistazo a mi reemplazo para NSXMLParser. Lee los datos XML de un flujo en lugar de mantenerlos todos en la memoria, y pasa 1KB a la vez a libxml (donde NSXMLParser se encarga de todo de una vez).
El código fuente está disponible en github y mi reseña sobre los aspectos de la memoria está en mi blog .
libxml2 es más rápido que NSXMLParser, así como más flexible. También tiene una pérdida de memoria muy pequeña (pero notable) con la interfaz xmlReader (mi interfaz favorita del conjunto) en el SDK lanzado con iPhone OS 2.2.1. Detalles incrustados en http://inessential.com/2009/02/25/moving_to_libxml2_sax2 . Otras interfaces dentro de libxml2 no tienen ese problema, solo que mi favorita sí lo tiene.
Funcionalmente, no notará la diferencia con cantidades relativamente pequeñas de XML, pero si se encuentra vadeando a través de un conjunto grande transmitido al analizador, se notará.
Como mencionó zPesk, para pequeñas cantidades de datos puede encontrar el beneficio de trabajar directamente con Objective-C más beneficioso que la pequeña cantidad de rendimiento que obtiene.
libxml2 siempre será más rápido que NSXMLParser por muchas razones, sin embargo, depende de usted cuál es más útil para su proyecto.
NSXMLParser, en general, es más bonito. El código tiene sentido, como se supone que es el analizador de saxofón, y es una verdadera clase de cacao con todas las convenciones allí. Si la comodidad y el código limpio son sus principales prioridades, entonces debe seguir con NSXMLParser.
Si bien NSXMLParser usa libxml2 en el backend, es más lento debido a los fundamentos de Objective-C y el talón de Aquiles de Objective-C. Al analizar XML, básicamente estás haciendo un montón de bucles ajustados una y otra vez mientras buscas las etiquetas que te interesan.
Aquí se encuentra la lección: cuando se encuentra en un bucle estrecho en el Objetivo C y no puede utilizar la enumeración rápida de objetos, está observando un impacto de rendimiento serio. Dispatch / Delegate respondsToSelector / y otras construcciones de lenguaje base de Objective C le dan una verdadera desventaja aquí.
No voy a entrar en el despacho, pero el problema es que cada vez que acceda a algo como esto: "[zomg lolz]" le está entregando una firma de método al despachador de object-c para encontrar la función C objetivo para Su firma del método Objective-C. Este proceso de búsqueda, cuando se realiza una y otra vez, puede reducir drásticamente su rendimiento.
Si tiene un iPhone, vaya a libxml2 y no mire hacia atrás, pero si su máquina de destino tiene dos procesadores y más RAM que dios, usaría NSXMLParser para facilitar el mantenimiento del código.
libxml2 siempre va a ser más rápido que NSXMLParser. NSXMLParser le proporciona una API decente basada en eventos, pero está construida sobre libxml2 y tampoco está basada en secuencias (por ejemplo, NSXMLParser entrega todo el bloque de datos a libxml2 a la vez).
Si está optimizando la velocidad, libxml2 es definitivamente el camino a seguir. Sin embargo, si desea una API basada en eventos obj-c y no le importa mucho el rendimiento, NSXMLParser es la herramienta adecuada para el trabajo. Y tenga en cuenta que NSXMLParser no es necesariamente lento, simplemente no es tan rápido como libxml2.
Si desea utilizar libxml2 con una parte frontal de Objective-C, eche un vistazo a este útil conjunto de funciones de envoltorio .
Emite una consulta Xpath a su objeto de documento XML y recupera los objetos de clase Foundation: NSArray , NSString y NSDictionary .
Estas funciones ayudan a unir la velocidad de libxml2 con la legibilidad del código Objective-C.