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

On Wed, 1 Oct 2003, Daniel Veillard wrote:

On Wed, Oct 01, 2003 at 09:55:53AM -0600, Steve Williams wrote:

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
     (*(int *) CUR) == abcd
     because valgrind complained about uninitialized memory access
     on such instructions when compiled with -O2 :-)

I would suggest then that that's an invalid optimisation - if you were
accessing a memory mapped device that might have very bad consequences
(*), not to mention the fact that there are alignment issues and the fact
that the memory following CUR may not even exist. If the compiler produces
broken code like that when optimising then I'd be concerned about using

I'm slightly surprised that there aren't any extent checks to see whether
the NXT runs off the end of the buffer, but I guess that there is a
guarentee that the data is sufficiently 'complete' within these blocks.

(*) Ignoring for a second that this operation is in LibXML2 and therefore
isn't going to be accessing a memory mapped device, but I can imagine a
circumstance where the cited sequence would be to access a memory mapped

Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
... Stuff happens.

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