c# interview question

[=?Utf-8?B?U3RldmUgQnVnZGVu?=]

Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunately I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it give
better performance?

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

[Jon Skeet [C# MVP]]

DeveloperX <nn*****@operam ail.comwrote:

I agree it's type safe, but the former passes an int and a string as
object parameters and the latter two strings to string parameters.
Given the choice I'd rather use the most accurate signature available
for what I want to do, in this case concat two strings. Ok, string
concatenation probably isn't the best example as it's really simple
and I do take your point on readability. I personally think I prefer
the ToString version as it's obvious that I want the int's string
representation. Imagine this example:

int i=1;
int j=2;
Console.WriteLi ne("My value is: " + i + j);
Console.WriteLi ne("My value is: " + (i + j));
Console.WriteLi ne(i + j);

Suddenly I get
My value is: 12
My value is: 3
3

So if a developer simply removed the string literal the intention of
the line of code changes.

I would never use the first form - always the second or third. They're
both perfectly readable, IMO, and I think string concatenation is
sufficiently "part of the language" that it's obvious that when I'm
concatenating a string and an int, that I want the string
representation of the int.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[DeveloperX]

On 12 Mar, 17:17, "Mike Schilling" <mscottschill.. [e-mail]>
wrote:

"DeveloperX " <nntp...@operam ail.comwrote in message

news:11******** **************@ c51g2000cwc.goo glegroups.com.. .

On 12 Mar, 10:45, "Mike Schilling" <a...@newsgroup .nospamwrote:

"Steve Bugden" <SteveBug...@di scussions.micro soft.comwrote in message

>news:60******* *************** ************@mi crosoft.com...

Hi,

I recently had an interview where I was asked a number of questions on
C#.
Unfortunately I didn't get the answers from the test and find that one
of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

By definition, they mean exactly the same thing, so it doesn't matter
which
one you use. (If it were possible for "i" to be null, the first one
would
be better, since it could never cause a null reference exception, but a
value type can't be null.) The analyses in other posts in the thread
aren't
about the difference between these two statements, they're about what IL
a
particular version of the compiler happens to generate. If these people
expect you to know that off the top of your head, they're idiots.
Likewise,
if these people think that the difference between the two sets of
generated
IL cause any measurable difference in performance, they're idiots.

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can
only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and
generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Sorry but that just isn't true.
The IL shows perfectly the different behaviours of the two lines. The
first will box into an object, call Concat(object, object) which
internally will call Concat(string, string). The second only calls
Concat(string, string) Any internal compiler optimisations would have
to honour that behaviour.

Why, when they result in identical behavior? C# is a high-level language,
not assembler.

So the IL disassembly shows exactly what the

difference between the two lines of code are and would not be markedly
different regardless of whether you compiled it under VS or say Mono.
The OP wanted to know what the difference was based on his interview
and he got several good answers.

Regarding performance. One is more performant than the other. Running
the above example won't yield a noticable difference in speed, doing
so with a more complex example in a tight loop over millions of
iterations would.

Can you demonstrate that? Seriously, build a test and tell us the results.- Hide quoted text -

- Show quoted text -

I showed the performance back up the thread,
I can try and compile something up under mono, but my assertion is
based on the fact they use ECMA-335 for the CIL and and 334 for C#.
Regardless of whether they've rewritten Concat(object, object) to look
slightly different to Redmond's interpretation, it will have to a) box
the int, b) call ToString on both the string and the now boxed int. c)
return the result.
These are the critical bits.

[Mike Schilling]

"DeveloperX " <nn*****@operam ail.comwrote in message
news:11******** *************@3 0g2000cwc.googl egroups.com...

I showed the performance back up the thread,
I can try and compile something up under mono, but my assertion is
based on the fact they use ECMA-335 for the CIL and and 334 for C#.
Regardless of whether they've rewritten Concat(object, object) to look
slightly different to Redmond's interpretation, it will have to a) box
the int, b) call ToString on both the string and the now boxed int. c)
return the result.
These are the critical bits.

Performance is something you measure. If it doesn't result in a measurable
performance different (e.g., if the JIT smooths out the difference), there's
no performance issue.

And that's aside from the fact that even if you can measure it, this sort of
micro-optimization would be about 10,000th on the list of things you should
worry about. It's like skipping lunch to improve your gas mileage.

[Brian Gideon]

On Mar 12, 4:39 am, Steve Bugden
<SteveBug...@di scussions.micro soft.comwrote:

Hi,

I recently had an interview where I was asked a number of questions on C#.
Unfortunately I didn't get the answers from the test and find that one of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it give
better performance?

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString());

But I can't think why this should give a performance advantage. I can only
guess that the compiler should be able to realise that a string is required
from the integer for the line not using the ToString() method and generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

Steve,

Console.WriteLi ne accounts for 99% percent of the execution time.
It's so significant, in fact, that when I ran tests I observed no
difference. Even after removing the method call I only observed a 5%
increase in speed by using the ToString() version. This micro
optimization is so insignificant that it's unlikely to ever be
perceptible in the context of an entire application.
The only thing that makes this interview question interesting to me is
that it asks "why?" at the end.

Brian

[DeveloperX]

On 12 Mar, 18:19, "Mike Schilling" <mscottschill.. [e-mail]>
wrote:

"DeveloperX " <nntp...@operam ail.comwrote in message

news:11******** *************@3 0g2000cwc.googl egroups.com...

I showed the performance back up the thread,
I can try and compile something up under mono, but my assertion is
based on the fact they use ECMA-335 for the CIL and and 334 for C#.
Regardless of whether they've rewritten Concat(object, object) to look
slightly different to Redmond's interpretation, it will have to a) box
the int, b) call ToString on both the string and the now boxed int. c)
return the result.
These are the critical bits.

Performance is something you measure. If it doesn't result in a measurable
performance different (e.g., if the JIT smooths out the difference), there's
no performance issue.

And that's aside from the fact that even if you can measure it, this sort of
micro-optimization would be about 10,000th on the list of things you should
worry about. It's like skipping lunch to improve your gas mileage.

To be honest Mike, I'm really not that interested. This thread has
gone totally off the rails. Concat is a red herring. You insist on
speaking in specifics while I deal with generalities. I posted the IL
to show that the int is boxed and it will then call Concat again. I
prefer using ToString because to my mind it indicates that I want a
string. In reality I'd probably use something more like the format I
used to output the three tick counts. For the sake of the interview
question I'd take the ToString version for the following reason:

Jon, I take your point regarding readability, I always do. In this
case I disagree to a point. As you say, it should always be implied
that if I + a string and an int I want the int's string
representation, my point was to show if you lose the string the +
reverts to a mathematical operator giving the wrong result (I have
seen this occur in code where a developer has changed how a composite
key was generated). Again, this is all very specific and not what I
originally intended to show.
I'd also argue that it's moot anyway. The majority of the time I'm
using a string builder, or not concatentating and having to use
ToString anyway. For that reason, I can also say I use it out of force
of habit.

Brian, in my example I removed all the WriteLine statements for
exactly that reason. I understand your point, I'm not going to have an
application that just Concats strings and then exits. Again, this is
too specific an example and I was responding to rage filled Mike in
his initial IL bashing. If I'm operating on a huge set of data I'll
take any optimisations I can get. If I can knock five minutes off an
hour long job it's worth it (to me, in my environment). I won't get
that from Concat sure, that's not really the point. This isn't a real
world test, it's a poor interview question that does not represent the
programming challenges we all face every day.

[RobinS]

I believe all value types have an inherent ToString method. I don't see why
one of these methods would be any different than the other.

Robin S.
--------------------------------
"glenn" <gl**********@y ahoo.co.ukwrote in message
news:e0******** *******@TK2MSFT NGP04.phx.gbl.. .

I'm wrong, of course it would compile.

Must read documentation before posting, must read documentation before
posting...

"glenn" <gl**********@y ahoo.co.ukwrote in message
news:uZ******** *****@TK2MSFTNG P02.phx.gbl...

>Steve

The code with the ToString() call would be quicker 'cus I don't think
the first would even compile.

Personally, I think it should have been

Console.WriteL ine( "This value is: {0}", i );

In this case ToString would be called anyway, so an explicit call to
ToString() is superfluous.

Glenn

"Steve Bugden" <St*********@di scussions.micro soft.comwrote in message
news:60******* *************** ************@mi crosoft.com...

>>Hi,

I recently had an interview where I was asked a number of questions on
C#.
Unfortunate ly I didn't get the answers from the test and find that one
of
them is still niggling me.

It was something like this:

Consider the following code:

int i = 0;
Console.WriteLi ne("The value is: " + i);
Console.WriteLi ne("The value is: " + i.ToString());

Which would you use to write an integer to the console and why would it
give
better performance?

I said I would use: Console.WriteLi ne("The value is: " +
i.ToString()) ;

But I can't think why this should give a performance advantage. I can
only
guess that the compiler should be able to realise that a string is
required
from the integer for the line not using the ToString() method and
generate
the same MSIL.

Can anyone please enlighten me?

Best Regards,

Steve

[Jon Skeet [C# MVP]]

DeveloperX <nn*****@operam ail.comwrote:

Jon, I take your point regarding readability, I always do. In this
case I disagree to a point. As you say, it should always be implied
that if I + a string and an int I want the int's string
representation, my point was to show if you lose the string the +
reverts to a mathematical operator giving the wrong result (I have
seen this occur in code where a developer has changed how a composite
key was generated).

I would always bracket things if there was any chance of it being
wrong, so it's not an issue for me, and the ToString() just adds fluff
as far as I'm concerned.

Again, this is all very specific and not what I
originally intended to show.

But it does address your incredulity that anyone would ever use a
non-optimal piece of code.

I'd also argue that it's moot anyway. The majority of the time I'm
using a string builder, or not concatentating and having to use
ToString anyway. For that reason, I can also say I use it out of force
of habit.

You don't have to use ToString() if you're using a StringBuilder - and
if you use StringBuilder where String.Concat would do the same thing,
*that's* less performant (and far less readable).

<snip>

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[DeveloperX]

On 13 Mar, 07:32, Jon Skeet [C# MVP] <[e-mail] wrote:

DeveloperX <nntp...@operam ail.comwrote:

Jon, I take your point regarding readability, I always do. In this
case I disagree to a point. As you say, it should always be implied
that if I + a string and an int I want the int's string
representation, my point was to show if you lose the string the +
reverts to a mathematical operator giving the wrong result (I have
seen this occur in code where a developer has changed how a composite
key was generated).

I would always bracket things if there was any chance of it being
wrong, so it's not an issue for me, and the ToString() just adds fluff
as far as I'm concerned.

Again, this is all very specific and not what I
originally intended to show.

But it does address your incredulity that anyone would ever use a
non-optimal piece of code.

I'd also argue that it's moot anyway. The majority of the time I'm
using a string builder, or not concatentating and having to use
ToString anyway. For that reason, I can also say I use it out of force
of habit.

You don't have to use ToString() if you're using a StringBuilder - and
if you use StringBuilder where String.Concat would do the same thing,
*that's* less performant (and far less readable).

<snip>

--
Jon Skeet - <[e-mail] >http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Yes, sorry I meant use ToString if I'm doing a direct assignment, but
not with StringBuilder, I should of bracketed my Or :)

A little incredulous, but not really. I'd rather my code was clean and
safe and performant. I've no problem with things like cascading
through a bunch of ctors because you only want to supply one of half a
dozen defaults. It may be faster to call the one that actually does
the work, but clearly asinine to supply all those default values each
time. Just an example.

Oh well as I said, The entire thread went off topic, my original
intention was to show the different operation of the two lines, I
didn't expect to be called an idiot for trying to explain how
something works, so apologies if I came across as overly defensive.

[Brian Gideon]

On Mar 13, 8:28 am, "DeveloperX " <nntp...@operam ail.comwrote:

Oh well as I said, The entire thread went off topic, my original
intention was to show the different operation of the two lines, I
didn't expect to be called an idiot for trying to explain how
something works, so apologies if I came across as overly defensive.

I certainly don't think you are an idiot. Afterall, you were
resourceful enough to ILDASM it to explore, understand, and explain
the differences in the two lines. I think most people would agree
that it's more important to demonstrate those skills to memorize the
answers to trick one-liners.

[Mike Schilling]

DeveloperX wrote:

time. Just an example.

Oh well as I said, The entire thread went off topic, my original
intention was to show the different operation of the two lines, I
didn't expect to be called an idiot for trying to explain how
something works, so apologies if I came across as overly defensive.

I wasn't calling you an idiot, but the interviewer, for

1. Considering this bit of trivia important, and
2. Expecting the OP to know it off the top of his head.

I disagree with you that there's clearly a performance issue here; there's
no way of telling that without knowing what the JIT output looks like, but I
wouldn't insult you over that.