[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [xml] xmlDoc or xmlNode



On Sun, Sep 28, 2003 at 09:57:32PM +0200, aliban gmx net wrote:
> hello list.
> i have some kind of benchmark question.
> 
> for my app i need to parse many little xml nodes...
> 
> in case i get a buffer filled with an xml "node" i have to build a 
> tree and then analyse it... i can parse the buffer with 
> 
> xmlDocPtr ptxmlDocPtr;
> ptxmlDocPtr = xmlParseMemory(ptchData, iSize);
> xmlFreeDoc(ptxmlDocPtr);
> 
> whatever this would happen quite many times...
> therefor i thought it might be less waste of cpu by not creating a 
> doc eacht time but instead to create/delete a node of a general doc 
> with the buffer.
> 
> Is it less cpu consuming to create/delete a node each time or does it 
> 
> make no difference?
> how to parse a buffer directly in a node? i would need a function 
> node xmlParseMemoryToParent(doc, parent, ptchData, iSize);
> 
> does it exist?

  Parsing is not defined in isolation. You cannot parse a "fragment"
independantly of the other parts of the document. Things like entities,
namespaces, ID/IDREF, etc. need the document and ancestors context to
work. There is a function in libxml2 to parse a "well balenced chunk"
though:
  int
  xmlParseBalancedChunkMemory(xmlDocPtr doc, xmlSAXHandlerPtr sax,
       void *user_data, int depth, const xmlChar *string, xmlNodePtr *lst) {

  it is complex, I don't recommend you use it.
W.r.t. speed, well creating a new parser context is anyway more costly
than creating a new document in general. See the upcoming APIs I discussed
in posts last week for an idea of how this could be solved [1].
But basically your approach is dangerous because parsing is only defined for
full documents.

Daniel

[1] http://mail.gnome.org/archives/xml/2003-September/msg00146.html

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]