3

I am looking for an XML library that supports a DOM interface. Performance is important for me so I was currently looking at rapidxml and also pugixml.

The thing is that my application needs to modify the DOM tree, including moving nodes. And I cannot see a direct way of doing this (neither with rapidxml nor with pugixml). It seems I need to copy/clone the nodes, which could lead to lots of copy operations if the subtree I want to move is quite deep.

Is there a more efficient way of doing this (either with rapidxml or with pugixml) (e.g. swapping the pointers, etc.)? If not, is there any other lightweight library that allows doing this?

Thanks!

user1192525
  • 657
  • 4
  • 18
  • Pugixml data structures support efficient moves within the same document but these operations have not been implemented. I'll try to do it today. – zeuxcg Aug 10 '14 at 18:48

1 Answers1

3

pugixml now (as of an hour ago) has ability to move node subtrees cheaply - see xml_node::prepend_move/append_move/insert_move_before/insert_move_after.

Note that these operations are not constant time - or rather the operations themselves are, but there is a validation step that guards against moving a node inside its own subtree (that would lead to the node being separated from the rest of the tree and causing memory leaks); this step has to traverse the ancestor chain of the new node location, making the move O(logN).

zeuxcg
  • 8,703
  • 1
  • 22
  • 33
  • Hi zeuxcg, thanks for your quick reply! I've seen the changes in trunk already. I suppose I could achieve O(1) instead of O(logN) by commenting out the invocation of allow_move(), couldn't I? (and under my own risk). Secondly, would it be possible to move a node out of the document (maybe by placing it on a temporary doc) and then putting it back into its original position (the reason for doing this is that I need to support 'undo'/'redo' operations in my application). Thanks again! I really appreciate your changes – user1192525 Aug 11 '14 at 02:20
  • Commenting out the invocation of allow_move() will disable both the O(logN) validation and the protection against moving the nodes from one document to another one. The reason why cross-document moving is not allowed is because node data lifetime is bound to the lifetime of the document. As long as you keep lifetimes of two documents the same this should actually be safe I think, but you can also consider storing the undo stack in a root-level node in the same document. – zeuxcg Aug 12 '14 at 03:28
  • Hi zeuxcg. Regarding your last comment and moving an object from one document to another. What I understand from your previous comment is that the lifetime of both documents must remain the same. Let's say I have moved all the nodes from Doc1 to Doc2, shouldn't be safe to delete Doc1? – user1192525 Aug 16 '14 at 11:49
  • No, it is not safe to delete doc1 even if you moved all nodes to doc2 since documents manage memory structures (specifically, document buffer with initial parsed text data and small allocation pages) that are used by all nodes in the document (note: the presence of these internal details is exactly why stock move implementation disallows cross-document moves - they are too easy to get wrong). – zeuxcg Aug 17 '14 at 04:58