From: Gregory Babior (babior@acceleratetv.com)
Date: Mon Feb 07 2000 - 14:04:23 EST
Glad I could help. By the way - in doing the following you can
keep a switch available to compile in either direction:
#define COMPILE_FOR_SPEED
#ifdef COMPILE_FOR_SPEED
/* keep the current NEXT macro as is */
#else
void nextFunc(xmlParserCtxtPtr ctxt)
{
// blah blah blah
}
#define NEXT nextFunc(ctxt)
#endif /* COMPILE_FOR_SPEED */
This works because (fortunately) in all instances of NEXT the variable
holding the xmlParserCtxtPtr has the same name (ctxt).
The best of both worlds, no??
As a reminder - I also found significant size gains in turning the macro
SKIP_BLANKS into a function. You can do the same thing with this
as done w/ the NEXT macro above - i.e. you can put in a switch so that
you don't have to sacrifice the speed if you wish to have it.
_________________________________________________
Gregory Babior Accelerate Interactive
Lead Software Architect babior@acceleratetv.com
310.822.4762 (v) 310.822.8160 (f)
330 Washington Blvd. Suite 800 Marina del Rey, CA 90292
-----Original Message-----
From: xml-request@rufus.w3.org [mailto:xml-request@rufus.w3.org]On
Behalf Of Daniel Veillard
Sent: Sunday, February 06, 2000 5:10 PM
To: Gregory Babior
Cc: Daniel Veillard; xml@rufus.w3.org
Subject: [xml] Re: embedded libxml
On Sat, Jan 15, 2000 at 08:36:28AM -0500, Daniel Veillard wrote:
> On Fri, Jan 14, 2000 at 11:21:51AM -0800, Gregory Babior wrote:
> > My current goal is to create a version of libxml that
> > is as small as possible so it can run in an embedded
> > system [...]
> > studying the code base I've found there are some compile time
> > options that could be added to improve the modularization
> > of the code and allow the ability to significantly shrink
> > the code size. The options I have in mind (so far) are:
> >
> > 1) An option to use function calls rather than macros.
> > Because of your consistent use of, for example, ctxt
> > in the NEXT macro, it's very easy to sub in a function
> > with minimal impact on the code - specifically
> >
> > void nextFunc(xmlParserCtxtPtr ctxt) { /* do stuff*/;}
> > #define NEXT nextFunc(ctxt)
>
> yep agree, I want first to do some profiling to estimate
> the inpact and gauge what should be the option by default.
Being stuck in an airport, I have looked at this.
I agree that the NEXT() macro is:
- used in a lot of places
- rather big
So I demacroified it as suggested in the XML and HTML parsers
Results of NEXT() demacroification on the XML parser
parse loop exec time size in bytes
before 9.66 124376
after 9.80 91320
This is a significant size improvement for a very small
speed penalty.
Results of NEXT demacroification on the HTML parser
parse loop exec time size in bytes
before 4.49 42800
after 4.63 38176
So as a whole I think that the size/speed tradeoff is more than
interesting, so I will make that change in the code base accordingly.
It is interesting to note that this simple change reduced the code
size by the same amount than the FTP, HTTP and the XPath code cumuled
(36 KBytes).
Thanks a lot for reporting this !
Daniel
-- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe ---- Message from the list xml@xmlsoft.org Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@xmlsoft.org---- Message from the list xml@xmlsoft.org Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@xmlsoft.org
This archive was generated by hypermail 2b29 : Wed Aug 02 2000 - 12:30:01 EDT