Re: [xml] RAW && NXT with strncmp()

[Daniel Veillard <veillard redhat com>]

On Wed, Oct 01, 2003 at 09:55:53AM -0600, Steve Williams wrote:
> Hi,
>
> Depending on the frequency of a match NOT occuring, the original code 
> could be significantly faster.  The first condition that did not match 
> causes the remaining comparisons to not happen.  If in 90% of the cases 
> (I have no idea the context of this code), the match is going to fail on 
> the (RAW=='<'), then the other two comparisons would NOT happen.
>
> This compared with the overhead of a function call every time...  but 
> then I'm an "old school" C programmer who considers things like speed.
>
> I'd be inclined to make a #define for the comparison if it occurs in so 
> many places.  But that's just me...

  To play the devil's advocate, on modern processors what's really
costly are caches misses. Sometimes doing a few more instructions
is better than having larger code or touching more data.
  I still thing the current tests are faster because the test values
are embedded as part of the instruction code. On the other hand this
makes the code bigger. Then there is maintainance issue etc.
  I stated I'm balanced over this issue, the points Igor raised are
real. I think most of the case are in areas which are not time critical.
However we can still look at performances a bit:
   - I think gcc -O2 inlines things like 
     CUR==a && NXT(1)==b && NXT(2)==c && NXT(3)==d
     as 
     (*(int *) CUR) == abcd
     because valgrind complained about uninitialized memory access
     on such instructions when compiled with -O2 :-)
   - using strncmp(CUR, static_string, len) 
     might also be inlined if it detects the string is immutable
 however if not inlined then it's not very good because you're breaking
the locality of accesses for both instructions and data.
 Hand-optimizing (*(int *) CUR) == abcd would probably make the code 
totally unreadable (need to check for byte ordering of the achitecture +
general uglyness of the cast :-) so I'm not going there, though if the
compiler does it for me it's nice.
 Maybe the best is to test both. Igor would you provide me a contextual
patch with those changes? I can't guarantee it will make into the final
code, but I can garantee I will check it seriously (including some 
valgrind/cachegrind/kcachegrind profiling checks).
 Okay let's say that if I get the patch it's likely I will apply it
unless results are really not good :-)

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/