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

[Justin Fletcher <justin fletcher ntlworld com>]

On Wed, 1 Oct 2003, Daniel Veillard wrote:

> 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 :-)

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

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

-- 
Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Stuff happens.