c# interview question

[Jon Skeet [C# MVP]]

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.WriteLine("My value is: " + i + j);
Console.WriteLine("My value is: " + (i + j));
Console.WriteLine(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.

 

[DeveloperX]

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

So the IL disassembly shows exactly what the



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]

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]

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.WriteLine("The value is: " + i);
Console.WriteLine("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.WriteLine("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.WriteLine 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]

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

 

[Jon Skeet [C# MVP]]

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>

 

[DeveloperX]

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.


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


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>

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]

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]

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.

 

[DeveloperX]

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.

Ah well that's ok then, sorry for the misunderstanding, I felt quite
annoyed at the time. I understand the context of your performance
comments and basically agree. In reality I'd be profiling the
application looking for tweaks and bottlenecks as opposed to
disassembling it and pouring over the IL, although there's every
possibility I'd apply such a tiny change if I thought the benefit was
there.

Well, I've picked up some interesting tidbits along the way, so it's
not all lost, so cheers guys and onward

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

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

Actually you were clearly referring to the other posters in the thread,
not the interviewer, when you state the criteria for being an idiot.
Claiming that everyone who don't share your opionions are idiots, is not
the best way of entering a debate. I can understand if people get upset
by that.

, for

1. Considering this bit of trivia important, and

That is only your opinion, and not sharing it is no reason to suspect a
lack of intellectual capacity.

2. Expecting the OP to know it off the top of his head.

I wouldn't expect anyone to know the answers to every question in an
interview. Then the questions are too easy, or the applicant overqualified.

I would however consider the answer that there is no difference between
the lines to be worse than admitting that you don't know the difference.

I disagree with you that there's clearly a performance issue here;

The given code clearly has no performance problems, but it demonstrates
boxing, which clearly can cause performance problems.

there's
no way of telling that without knowing what the JIT output looks like,

Sure there is. Examining the IL code works just as well.

 

[PFC Sadr]

Q) Do you use C#
A) Don't hire anyone that says YES; because VB is an obviously
superior langauge with greater code portability

 

[Nitin Sharma]

int i = 0;
//This will use implicit conversion
Console.WriteLine("The value is: " + i);
//This will not use implcit conversion as we already declared ToString()
so Performance will be fast.
Console.WriteLine("The value is: " + i.ToString());
Console.Read();

Nitin Sharma
(Guru .Net)

 

[Brian Gideon]

int i = 0;
//This will use implicit conversion
Console.WriteLine("The value is: " + i);
//This will not use implcit conversion as we already declared ToString()
so Performance will be fast.
Console.WriteLine("The value is: " + i.ToString());
Console.Read();

Nitin Sharma
(Guru .Net)

*** Sent via Developersdexhttp://www.developersdex.com***

There is no implicit conversion from int to string. I just checked
the C# specification to make sure. DeveloperX already explained why
the later is faster several posts up. Also, as written, the
performance of those two lines is nearly identical.