«

Assuming I have the following:

byte[] bytes = new byte[100];
int pos = 0;


which is faster:

pos++;
pos %= bytes.length;

or:

pos = ++pos % bytes.length;


Thanks in advance,

Bob

wrote on 06.10.2006 18:35:
> Assuming I have the following:
>
> byte[] bytes = new byte[100];
> int pos = 0;
>
>
> which is faster:
>
> pos++;
> pos %= bytes.length;
>
> or:
>
> pos = ++pos % bytes.length;

Who cares?

Thanks Thomas How's HSQLDB?

Thomas Kellerer wrote:
> wrote on 06.10.2006 18:35:
> > Assuming I have the following:
> >
> > byte[] bytes = new byte[100];
> > int pos = 0;
> >
> >
> > which is faster:
> >
> > pos++;
> > pos %= bytes.length;
> >
> > or:
> >
> > pos = ++pos % bytes.length;
>
> Who cares?

wrote:
> Assuming I have the following:
>
> byte[] bytes = new byte[100];
> int pos = 0;
>
>
> which is faster:

It does not matter. And if it would be really an important issue for
you, you would measure it.

/Thomas
--
The comp.lang.java.gui FAQ:
http://gd.tuwien.ac.at/faqs/faqs-hie...lang.java.gui/
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq

I don't believe measuring it on one platform is sufficient, since my
program is deployed on many platforms. The code is in a method at the
high end of the execution chain, which I would like to optimize as much
as possible. If it truly doesn't matter, then I'll go with the more
maintainable solution (since its a 1 liner):

pos = ++pos % bytes.length;

Bob


Thomas Weidenfeller wrote:
> wrote:
> > Assuming I have the following:
> >
> > byte[] bytes = new byte[100];
> > int pos = 0;
> >
> >
> > which is faster:
>
> It does not matter. And if it would be really an important issue for
> you, you would measure it.
>
> /Thomas
> --
> The comp.lang.java.gui FAQ:
> http://gd.tuwien.ac.at/faqs/faqs-hie...lang.java.gui/
> ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq

[post re-ordered]

<> wrote in message
news: oups.com...
> Thomas Weidenfeller wrote:
>> wrote:
>> > Assuming I have the following:
>> >
>> > byte[] bytes = new byte[100];
>> > int pos = 0;
>> >
>> >
>> > which is faster:
>>
>> It does not matter. And if it would be really an important issue for
>> you, you would measure it.
>>
>
>I don't believe measuring it on one platform is sufficient, since my
> program is deployed on many platforms.

So measure it on enough platforms for it to be sufficient?

> The code is in a method at the
> high end of the execution chain, which I would like to optimize as much
> as possible. If it truly doesn't matter, then I'll go with the more
> maintainable solution (since its a 1 liner):
>
> pos = ++pos % bytes.length;

FWIW, I think this is less maintainable, as it is an expression which
assigns to the same variable twice, which many programmers find confusing.

- Oliver

Oliver Wong <> wrote:

> > pos = ++pos % bytes.length;

> FWIW, I think this is less maintainable, as it is an expression which
> assigns to the same variable twice, which many programmers find confusing.

Not to mention that programmers, such as myself, with a C or C++
background are likely to berate such code's author for invoking
dreaded Undefined Behavior before realizing that Java at least
improved the situation by guaranteeing the behavior of that code.

As a contradictory data point, however, it seems that IntelliJ will
not generate an inspection warning on that code; I was sure it would
have complained about the stylistic dubiousness of it, but apparently
not.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

wrote:
> I don't believe measuring it on one platform is sufficient, since my
> program is deployed on many platforms. The code is in a method at the
> high end of the execution chain, which I would like to optimize as much
> as possible. If it truly doesn't matter, then I'll go with the more
> maintainable solution (since its a 1 liner):
>
> pos = ++pos % bytes.length;

"Code is usually clearer when each expression contains at most one side
effect, as its outermost operation..."
http://java.sun.com/docs/books/jls/s....doc.html#4779

This line is particularly bad, because both side effects modify pos, and
the one done by ++pos is dead - only the value of the expression is ever
used.

What is wrong with this?

pos = (pos + 1) % bytes.length;


As far as performance is concerned, I would examine the method in terms
of two key issues:

1. Cache hit vs. cache miss.

2. Conditional branches, and especially conditional branch predictability.

A single cache miss, or a mispredicted branch, will cost far, far more
than changes in exactly how you do a little arithmetic, using the same data.

Patricia

wrote:

> I don't believe measuring it on one platform is sufficient, since my
> program is deployed on many platforms.

Which is sensible, but if you can't measure it on all your target platforms,
then how do you expect us to know which is faster without even knowing what
those platforms are, or which are most important to you ?


> The code is in a method at the
> high end of the execution chain, which I would like to optimize as much
> as possible. If it truly doesn't matter, then I'll go with the more
> maintainable solution (since its a 1 liner):

It is perfectly possible (though, I'd guess, not too likely) that if this code
is in the inner loop of your application then its speed is critical for the
overall app. If you suspect that might be the case then /measure/ it.

BTW, when you do measure (if you bother), don't forget to test a version
without the modulus operator:

if (++pos >= bytes.length)
pos = 0;

It involves a branch (but one which, I imagine, would normally be correctly
predicted by the CPU -- if you are running on a machine with instruction
pipelining and branch prediction), but saves a mod operation. You (unless you
know a lot more about your target architectures than you have said) can't guess
which is quicker, so -- again -- you have to measure it. I might be worth
putting bytes.length into a local variable too, OTOH that might be a waste of
time -- it depends on whether the optimiser in the JIT (if any, on your target
platforms) spots the repeated use of bytes.length by itself.


But, whatever you do, DON'T use:

> I'll go with the more
> maintainable solution (since its a 1 liner):
>
> pos = ++pos % bytes.length;

It pre-increments pos and assigns to it -- which is just daft.

-- chris

>>> pos = ++pos % bytes.length;

> Oliver Wong <> wrote:
>> FWIW, I think this is less maintainable, as it is an expression which
>> assigns to the same variable twice, which many programmers find confusing.

Then they aren't very good programmers. In fact, I recommend that one use
this type of example as an interview question to avoid hiring those who find
it confusing.

Christopher Benson-Manica wrote:
> Not to mention that programmers, such as myself, with a C or C++
> background are likely to berate such code's author for invoking
> dreaded Undefined Behavior

Slightly O-T, but doesn't C[++] guarantee behavior across the assignment,
i.e., that the right side is fully evaluated before storing to the left?

As you point out, Java does make this guarantee.

Just to complicate matters, there's another idiom that replaces the overhead
of the mod operator and second assignment with the overhead of a test-and-branch:

if ( ++pos == bytes.length )
{
pos = 0;
}

- Lew