Re: [xml] too many mallocs?

[Daniel Veillard <veillard redhat com>]

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
> results:
>
> 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.

   okay,

> 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 
> processors,

   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 
> conditional.

  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

-- 
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/