Memory not freed using remove_child()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I am expecting xml_node::remove_child() function to free the memory of the 
child. It is not doing so because of checks if(!name_insitu)/if(!value_insitu)  
in xml_node::destroy() function and the default values of 
name_insitu/value_insitu are true. Is there any reason for this?

Can I change default values of name_insitu and value insitu to false?

Original issue reported on code.google.com by vishnu.i...@gmail.com on 20 Jun 2010 at 2:23

[GoogleCodeExporter]

For efficiency reasons, during XML parsing the names/values are allocated in 
the XML text (insitu); freeing a single string is impossible. When you're 
constructing the node manually (i.e. set_name/set_value), the strings are 
allocated on heap, and they are removed by remove_child. insitu is set to false 
for heap-allocated strings.

So this behavior is by design. What is your pattern of usage - i.e. are you 
doing very large-scale modifications (i.e. a lot of nodes from the original 
document are removed)? Do you want to optimize for peak memory usage or for the 
total memory consumption after document processing is finished?

Original comment by arseny.k...@gmail.com on 20 Jun 2010 at 8:01

[GoogleCodeExporter]

By the way, the insitu-allocated strings are (of course) freed upon document 
destruction, so if you try to reuse xml_document instance by deleting all 
top-level children and then construct a new tree there - don't do that (create 
a new instance), or do doc.load(""); instead.

Original comment by arseny.k...@gmail.com on 20 Jun 2010 at 8:04

[GoogleCodeExporter]

Thanks for that reply. I was holding onto a document and updating a child node 
multiple times(in the process removing the existing node)
for example if <xml><node>....</node></xml> is my document and i needed to 
update the node <node> with another node (using remove_child() and append_copy 
with updated <node> which I got from another document) the heap size kept on 
increasing. 

Actually, I ended up calling load on the document before doing the update which 
calls destroy on the existing document. 

Original comment by vishnu.i...@gmail.com on 20 Jun 2010 at 9:39

[GoogleCodeExporter]

I see. Calling load if you're adding the whole tree from scratch is the right 
thing.

Also if you're using version 0.5, remove_child won't destroy the node memory 
(i.e. xml_node_struct/xml_attribute_struct); calling load does destroy it.
This has been fixed in the repository, the new version with lots of changes 
including this one is scheduled for the beginning of July. You can use the 
repository version in the meantime if you need this.

Original comment by arseny.k...@gmail.com on 21 Jun 2010 at 5:28

[GoogleCodeExporter]

In the new release (version 0.9, you can grab it from Downloads section) 
remove_child and remove_attribute deallocate as much memory as they can. The 
huge chunk with the document contents that's allocated upon load is still left, 
of course - this is by design.

Original comment by arseny.k...@gmail.com on 11 Jul 2010 at 5:17

• Changed state: Fixed