Re: [gdome] Gdome providing free()

Luca Padovani wrote:
> Hi Blair,
> On Mon, 2003-03-17 at 21:39, Blair Zajac wrote:
> > I haven't looked at the GdomeDOMString code yet, so does this require a string
> > copy?  I'd like to minimize these.
> GdomeDOMString does NOT copy the string returned by libxml2, it only
> wraps the pointer returned by libxml2 within another little structure,
> but I understood your main concern (as by email subject) was the fact
> that one has to use the right deallocator when freeing memory allocated
> by libxml2. So what I'm saying is that GdomeDOMString will use the right
> deallocator, hence it will fix the problem reported for this particular
> email thread, however...

Looks like gdome_str_mkref_xml would do the trick really easy without
making a copy, but the comment says is deprecated.

 * gdome_str_mkref_xml:
 * @str:  a %NULL terminated string
 * Creates a #GdomeDOMString from a xmlChar buffer already allocated by libxml.
 * Returns: the new DOMString object.

I did a grep on libxml, xmlChar and didn't find a suggested replacement

Any hints?  Should I just use gdome_str_mkref_xml?

> > The idea sounds good, assuming we can minimize making copies.
> [slightly off-topic]
> still need to use copy_string in the Ocaml binding. This is usually not
> a major concern, unless the string you're duplicating is really large (which
> might well be given that it is an entire serialized XML document). In that
> case, my objection is that the principle of serializing the document (to a
> string) is the real problem, and that you should seek for a smarter solution
> that passes the document to the receiving application without serializing.

The serialized document is being dumped into a MySQL table, so there's
really no choice about that, as MySQL can't store a tree structured document.

> BTW, I think that the time for serialization itself overwhelms the time for
> scanning to the end of the string, or for duplicating it any way, so probably
> trying to minimize string duplication is only going to affect an irrelevant
> slot of time for the whole operation, and will give us headache...

OK.  Granted, don't want to make too many API changes here and too much
work for us.


Blair Zajac <blair orcaware com>
Plots of your system's performance -

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