Re: memory allocations / libxml

[Daniel Veillard <veillard redhat com>]

On Mon, Mar 04, 2002 at 09:01:11PM +0000, Michael Meeks wrote:
> Hi Daniel,
> 
> 	Oh dear, it seems I screwed up the communicating business again,
> bother:
> 
> On Mon, 2002-03-04 at 10:35, Daniel Veillard wrote:
> > > 	Is that an easy thing to do Daniel ? clearly I'd rather use libxml than
> > > writing my own XML parser :-) we already use the fast SAX interface.
> > 
> >   No idea what you're speaking of. Write your own parser, and maintain it !
> 
> 	Precisely what I don't want to do :-) the smiley was if anything a grin
> at Havoc, personally I don't think writing my own parser is a terribly
> profitable use of time when we have two that work well already,
> especially if I can help speed up every libXML user's parsing experience
> in the process. 

  I still didn't see how this relates to libxml . Your "pseudo code"
did NOT look like libxml one. And I internally do xmlStrdup() when I need
them. Again "No idea what you're speaking of".
  the issue started on attribute parsing speed, I explained why I had to
normalize attributes (it is a requirement for XML processing) and why I had
to extract the strings anyway due to the SAX API.
  I have seen 0 useful information from your part except "Use alloca"
which I have a hard time to see why/how it would help.

> >   Again no idea what you're speaking about. Allocca is not portable,
> > I won't use it .
> 
> 	Alloca works on any platform that glib runs on, and is 2-3 (?) orders

  Libxml works on a set of platform far larger than glib. 
    http://mail.gnome.org/archives/gdome/2002-February/msg00008.html
    Enjoy !

> of magnitude faster than malloc/free, of course, I have no idea what I'm
> asking for - which is an advantage in asking boldly, but is it so much
> to as for:
> 
> 	len = token_length;
> 
> 	if (len > 64)
> 		dup = xmlStrndup (buf, len);
> 	else {
> 		dup = g_alloca (len + 1);
> 		memcpy (dup, buf, len);
> 		buf[len] = '\0';
> 	}
> 
> 	ctxt->fooCb (ctxt, dup);
> 
> 	if (len > 64)
> 		xmlFree (dup);

  Where / how / would you maintain that ugly code ? I would not ! You would
have to be sure your code ain't slower actually, and in a lot of case the
lenght f the buffer ain't availble, so add an extra xmlStrlen() penalty to
your alloca path, also from where do you extract that magical 64 value ?
  Maybe there is something to save from this but it would need quite some
work to become maintainable and portable.

> 	If it can kill the locking penalty, and thus improve parsing speed for
> all the Gnome code, is that worth doing ? wait I'll read libxml a bit
> and see ...

  What I love about this rant on libxml2 performances looking like it simply
sucks rocks is that apparently libxml2 is probably the fastest conformant
XML parser one can find to build a DOM tree, on par with Microsoft
MSXML4 and clearly faster than Xerces.
  Are you by chance looking for a problem to solve ???? I'm tempted to say
you could find other places.

> >    I will fix it the day you will report it normally. I.e. either by
> > posting the problem on the mailing list of through bugzilla. Sending mail
> > ending up in my inbox are getting there with 500 others and possibly deleted
> > discarded or forgotten. Time you learn about process ...
> 
> 	Oh dear, I've done it wrong again - personally I prefer E-mail you see,
> so I tend to think everyone else does, apologies. I've filed a bugzilla
> bug for you: http://bugzilla.gnome.org/show_bug.cgi?id=73430.

  Okay got it, I will process it, should not be too hard.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers