Re: [[libxml++] Reduce overhead of unhandled SAX events]

[Jonathan Wakely <cow compsoc man ac uk>]

On Fri, Feb 21, 2003 at 08:42:41AM -0000, Murray Cumming wrote:

> Like all optimisations, particularly ones that make the API less clear, I
> think we should first show that this optimisation would make a significant
> differnce, for instance by using a profiler.

Of course.  I want to add handlers for some more SAX events to my local
version of libxml++, so when I've done that I'll see what effect the
extra handlers have on programs that don't use them, and see if the
patch makes a difference.

> Jonathan Wakely <cow compsoc man ac uk> wrote:
> > G'day all, bit of a long one this, sorry ...
> > 
> > I've submitted a patch to SF that allows a derived SaxHandler to specify
> > which events to handle, so when the default libxml2 implementation is
> > suitable there is no additional overhead.
> > 
> > Currently each SAX event handled by the xmlpp::SaxParser class has an
> > overhead of calling the static callback function and the virtual handler
> > function.  If a user doesn't care about a particular event and doesn't
> > override the relevant virtual function they still pay the overhead for
> > the two functions, and then fall back to the libxml2 implementation.
> > This adds two function calls to the C library equivalent, only one of
> > which could be inlined in most cases (the non-virtual one). This goes
> > against the C++ philosophy of not paying for features you don't use
> > (and gives ammo to those who say C++ is inherently inefficient, grrr!)
> > 
> > This isn't a big deal at the moment, as the events that libxml++ can
> > handle are the common ones that most people will override in their
> > derived parser, but if more events were supported (e.g. entityDecl,
> > resolveEntity etc.) all users of the base class would have the
> > additional overhead for these events, despite the fact that the
> > libxml2 implementation is fine for most people.
> > 
> > The patch adds a protected constructor taking an xmlSAXHandler struct.
> > The new constructor initialises _sax_handler with the supplied struct,
> > allowing the derived class to specify which callbacks should be enabled
> > (for a derived class to do this the callbacks must be protected).  For
> > now all this does is let a derived class specify that certain events
> > shouldn't be handled, however as new events are supported by libxml++
> > and relevant callbacks and virtual functions added this extra ctor
> > becomes more useful.  The new handlers could be disabled by default, but
> > a derived class can enable them using the new ctor.  This allows you to 
> > provide handlers for every event supported by libxml2, with no
> > additional overhead for the events you don't use (actually, I think the
> > vtable will be slightly larger, so there's a slight space overhead for
> > each additional virtual function).
> > 
> > Alternatively, rather than adding new functions to the base class an
> > extended ExtSaxParser class could add new callbacks and virtuals to the
> > base class, and assign them to the xmlSAXHandler that is passed to the
> > base ctor. This would keep the base class simple, using subtypes for
> > extensions (although since there's no overhaed I'd prefer to extend the
> > base class by adding the functions there and disabling them by default)
> > 
> > The downside, as I see it, is that we're exposing implementation detail
> > by making the callback functions visible to derived classes.
> > 
> > All comments welcome,
> > 
> > jon
> > 
> > 
> > -- 
> > "If you can't say anything good about someone, sit right here by me."
> > 	- Alice Roosevelt Longworth
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> > The most comprehensive and flexible code editor you can use.
> > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > www.slickedit.com/sourceforge
> > _______________________________________________
> > Libxmlplusplus-general mailing list
> > Libxmlplusplus-general lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
> 
> 
> 
> Murray Cumming
> murrayc usa net
> www.murrayc.com
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Libxmlplusplus-general mailing list
> Libxmlplusplus-general lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

-- 
"And God said, Behold, I have given you every herb bearing seed,
 which is upon the face of the earth ... to you it shall be for meat."
	- Genesis 1:29