Re: [xml] too many mallocs?

On Thu, May 23, 2002 at 07:12:43PM +0200, Peter Jacobi wrote:
  is that with the CVS version ?

Sorry, no (I had problems downloading the snapshot, now it works!).

This was done with 2.4.21

  okay, and can you reproduce the same with the snapshot ?

BTW: Other optimizing attempts, which gave rather thin

1) In xmlParseEndTag, don't call xmlParseName but a new stripped down
xmlParseNameAndCompare which can avoid NameChar checking and
one malloc.

  okay, I would expect that to be thin .... attribute() in SAX.c is 
probably a better target for investigations.

2) Dis-Inline all but the first line of GROW and SHRINK

  and making the remaining a function ? sounds sensible.

Gives about 5% each in best case. I will retry these against the CVS 
version and after I got hold of the bigger causes of inefficency.


BTW2: (Sorry for scholarizing [if this word exists]) I'm under the 
impression, that some coding style in libxml2, isn't a good fit for modern 

   since my PhD in OS is now 6-7 years old, some refreshing is welcome :-) !

if we try to save essential nanoseconds: The macros (you 
already have reverted the bigger ones to functions) enlarge the code size 
and hit the branch target buffer badly, if they contain more than one 

  Okay it's not the use of MACROs which at stake here but the possible
associated duplication of conditions in the resulting code. Agreed for
SHRINK, GROW this might make sense, some macros simply expand functions, 
and others like NEXTL or SKIP might be difficult to change. The good 
point about the macros is that I tend to use them in a variety of
context especially for parsers they help clarify the code, and make global
changes easilly. Now I didn't looked at the cost of instruction processing
in the last 8 years, so maybe things changed radically :-)

The multiple returns from a function will also trash the branch 
target buffer. (Not that you or anybody else should have sleepless nights 

  Well I have trouble believing it's better than issuing a jmp + a ret
especially since RISC tend to have one delay slot on the ret, which can
precisely be used effectively by an immediate return in the middle of a
while it would be lost by a jmp + return. So I'm less sure about this one
this would require precise examination of the assembly produced on recent
platforms + compilers ;-)

from this).

  Don't worry I have already enough reasons to be sleepless ...


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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