Difference between int i, j; and int i; int j;

[arun]

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

Thanks,
arun,,

[Ico]

arun <ar****************@gmail.comwrote:

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

There might, or there might not; this depends completely on your
implementation. If you want to know, measure it. Or - if your toolchain
allows you to - look at the generated assembly code to see if there is
any difference.

--
:wq
^X^Cy^K^X^C^C^C^C

[Richard Bos]

"arun" <ar****************@gmail.comwrote:

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

Wrong question entirely.

Imprimis, it's impossible to say anything at all with the absolute
certainty you probably suspect without knowing the exact details of a.
the compiler b. the platform you compile on c. the platform you run the
program on d. the options used when compiling e. the rest of the code f.
the configuration of any machine involved and g. the phase of the moon.

Secundis, even with all that knowledge, indeed even without it, it is
quite obvious that any reasonable compiler would compile both of those
snippets completely identically, _but_ you're not guaranteed that your
compiler is reasonable.

Tertiis, unless you know with 99.99% certainty that the difference is a
real problem for you, don't worry about it. Premature optimisation is
the root of much evil.

Richard

[Chris Dollin]

arun wrote:

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

The C standard doesn't say anything about performance.

Whether or not there is a difference depends on the particular implementation.
Suck it and see.

If there /were/ a difference, I would be gobsmacked. When I picked my jaw
back up off the floor, I would likely switch to a saner compiler.

--
Chris "detachable jaw" Dollin
"A facility for quotation covers the absence of original thought." /Gaudy Night/

[John Bode]

arun wrote:

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

Thanks,
arun,,

The only way to know for sure is to compile and run both versions and
use a profiling tool to compare performance. Having said that, I can't
imagine that there would be a measurable difference in runtime
performance between the two (a sane compiler should generate
essentially the same machine code for the two versions), and I doubt
it would have a measurable effect on build times either.

[Eric Sosman]

arun wrote:

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

The first uses ten characters (including a newline), while
the second uses fourteen. If you use the first form in preference
to the second often enough, the four-byte savings will eventually
accumulate to the point where your editor fewer disk I/O operations
to write the file and your compiler uses fewer I/Os to read it.
I/O is vastly slower than almost anything else a computer, so the
first form is faster. (It also takes less typing, which is an
an even greater savings.)

Aren't you glad you asked? To what use will you put your
newfound knowledge?

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob navia]

arun a écrit :

Hi all,,

I want to know if there is any performance difference between the
following sets of declarations.

int i, j;

and

int i;
int j;

Thanks,
arun,,

Normally there will be never any difference.

Subtle processor dependent features can make a difference
in the stack layout, but not in this case where the layout
is probably the same.

In some processors
(1)
int fn(void)
{
char buf[2024];
int counter;
}

will make a performance difference with
(2)
int fn(void)
{
int counter;
char buf[2024];
}

If the stack variable "counter" is in the stack and is used a lot,
each access will use a shorter instruction in case (2), since
the offset from the frame-pointer is less than 128 bytes and
can use shorter instructions.

This could make 0.000001% of efficiency gain in some processors.
This supposes a compiler that does NOT optimize this by
making stack layout independent from declaration order!

Short answer:

Do not worry about this kind of details.

jacob

[Mark McIntyre]

On Mon, 24 Jul 2006 15:00:04 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Subtle processor dependent features can make a difference
in the stack layout, but not in this case where the layout
is probably the same.

This bit is perhaps true, but dangerous to put first.

>Short answer:

Do not worry about this kind of details.

This is the bit to put first - many people would not have read this
far, and would therefore have missed the best advice !
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Dave Thompson]

On Mon, 24 Jul 2006 15:00:04 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:
<snip>

In some processors
(1)
int fn(void)
{
char buf[2024];
int counter;
}

will make a performance difference with
(2)
int fn(void)
{
int counter;
char buf[2024];
}

If the stack variable "counter" is in the stack and is used a lot,
each access will use a shorter instruction in case (2), since
the offset from the frame-pointer is less than 128 bytes and
can use shorter instructions.

Unless the compiler is halfdecent (most are nowadays) and the
processor is also (x86 isn't) then it will keep counter in a register
and not in the stack at all. <pedanticAssuming of course there is a
single stack and automatic variables are (normally) in it, which are
common but not required and not universal. </>

And not on Tandem NonStop where the first will (naively) use
counter L+1
buf L+2,S or L+3,S or L+2,X or L+3,X depending on modes
and the latter will use
buf L+1,S or L+1,X depending on modes
counter L+2 or L+3 depending on modes
and the code generated will do exactly the same number of virtual
accesses either way; physical performance may be affected by cache
differences, but that could go either way depending on a large variety
of factors that can't practically be predicted or probably even
measured, and similarly on many (most?) other platforms.

Although there are _other_ cases where ordering of declarations would
make a difference on TNS, some of which would make _no_ difference on
the platforms/implementations you are familiar with.

This could make 0.000001% of efficiency gain in some processors.
This supposes a compiler that does NOT optimize this by
making stack layout independent from declaration order!

or use registers, as above.

Short answer:

Do not worry about this kind of details.

Agree there.

- David.Thompson1 at worldnet.att.net