I don't think the call to xmlNodeSetContentLen() is needed here and

I don't think the call to xmlNodeSetContentLen() is needed here and
it is causing performance problems because it tries to parse the blob
and create a subtree.  Because we are escaping the string anyway, we
are never going to get a subtree, but the entity parsing that is done
by xmlNodeSetContentLen() is killing performance on large blobs of
text.  On one recent example it took a couple of minutes to parse
whereas if we just create a text node like this and set the contents
to the raw string it is down to milliseconds.  As far as I can tell
all the tests pass with this patch.