So - running evo. I end up with a growing number of e-d-s threads fighting
for 100% of my CPU - this is not good.

The stacktrace of one looks like this:

(gdb) bt

+ Trace 56531

$4 = (
    const xmlChar *) 0x415c6008
"BEGIN:VCARD
\nVERSION:3.0
\nX-EVOLUTION
-LIST:TRUE
\nX-EVOLUTION-LIST-SHOW_ADDRESSES:TRUE
\nUID:206AEC01-231A-00
00-99FF-0050DA7950E0@58:GroupWiseSystemAddressBook@52
\nX-EVOLUTION-FILE-A".
..
(gdb) p strlen(content)
$5 = 1428469

ie. we are calling xmlNodeSetContent with a 1.5Mb string.

_Clearly_ this method is not designed [ at all ] to parse a huge blob of
XML; and it's doing so in a horrifically inefficient way.

Quite apart from that, it seems pretty shocking to have this huge blob of
XML in a single, contiguous chunk of memory, the design is prolly broken
somewhere here.

If you want to parse a large static XML string, the best way to do it is
with the libxml parser API. Of course - why you want to turn 1.5 MB of
string into another set of hundreds of _Extremely heavyweight_ xml node
items I have no idea [ that will prolly double the size of the data ].

Are you certain you don't want to be using a light-weight SAX parser here;
eg. libbonoboui/bonobo/bonobo-ui-node (bonobo_ui_node_from_string) coupled
with your own more efficient representation ?