Which is faster

  • Thread starter Thread starter niteshs
  • Start date Start date
N

niteshs

Hello all, just checking which method is faster

string A;
A = "";

if (A == string.Empty)
{
MessageBox.Show("a is empty");
}
else
{
MessageBox.Show("a is not empty");
}
//or is this quicker
if (A.Equals(""))
{
MessageBox.Show("a is empty");
}
else
{
MessageBox.Show("a is not empty");
}
The argument here is in the first method we are using the string
property empty and then the equality == and in scenario 2 we are using
the object method equals to compare(so inside == we are calling Equals,
make sense, is == overloading Equals() ?), thus which 1 is
quicker...debating this with sum1 so we tht we'd post it here
hope we on the right track...
chow
 
hi

The big question is, does it matter that much?

If the answer is YES, then put the code inside a loop of 10K iterations and
see which is faster.


cheers,
 
Hello all, just checking which method is faster

I believe

if ( A.Length == 0 )

is somewhat faster on current implementations. But unless you're going
to run this code lots and lots of times, it probably doesn't matter
and I suggest you write what you find easiest to read.



Mattias
 
Hello all, just checking which method is faster

string A;
A = "";

if (A == string.Empty)
{
MessageBox.Show("a is empty");
}
else
{
MessageBox.Show("a is not empty");
}
//or is this quicker
if (A.Equals(""))
{
MessageBox.Show("a is empty");
}
else
{
MessageBox.Show("a is not empty");
}
The argument here is in the first method we are using the string
property empty and then the equality == and in scenario 2 we are using
the object method equals to compare(so inside == we are calling Equals,
make sense, is == overloading Equals() ?), thus which 1 is
quicker...debating this with sum1 so we tht we'd post it here
hope we on the right track...
Click to expand...

Well, they have different semantics - the first won't blow up if A is
null, whereas the second will throw an exception.

If you're *really* just after speed and already know that A is non-
null, I believe that using A.Length==0 is faster than either of the
methods above. However, I would *strongly* urge you not to micro-
optimise in this way - write the code in whatever way you find most
readable, and then look at the performance of the system overall, and
if you need to improve it, find bottlenecks and try to optimise those
if you have to.
 
if(A.Length==0)
MessageBox.Show("a is empty");
else
MessageBox.Show("a is not empty.");

would be faster than either.

NOTE, however, that none of these incurs a huge amount of overhead. It is
when you start manipulating strings that you end up with a lot of overhead,
like:

string x = String.Empty;

for(int i=0;i<100;i++)
{
x += i.ToString();
}

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
It is interesting that the string.Length == 0 optimization has been added to
FxCop as a default rule. If you check against "" you will get a warning or
error from FxCop. It would have been trivial to put the optimization in the
compiler. Checking Length == 0 is clumsy because you must often first check
to see if the string is null:

if (string1 != null && string1.Length == 0)


Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor
 
Frank Hileman said:
It is interesting that the string.Length == 0 optimization has been added to
FxCop as a default rule. If you check against "" you will get a warning or
error from FxCop. It would have been trivial to put the optimization in the
compiler. Checking Length == 0 is clumsy because you must often first check
to see if the string is null:

if (string1 != null && string1.Length == 0)
Click to expand...

Absolutely - if you don't know that the string is non-null, it's much
less readable than other ways.

I think it's a bad FxCop rule, myself, but there we go...
 
After 20 years in the programming industry, I have had only one job in
which this sort of thing mattered: programming telephone switches. That
type of programming had hard, real-time deadlines that had to be met,
so every cycle counted. Of course, if I were still doing that today, I
wouldn't be using C#. That would be silly.

In every other job I've ever had, one rule reigns supreme: you get far,
far more speed advantage out of choosing the right design and the right
data structures than you ever will tweaking code. True, sometimes you
run a profiler on your code and discover some part of it that could use
tweaking, but in my experience that is very rare (unless you're in one
of those intense areas of programming that requires raw speed or has
real-time deadlines).

I find it far more common to see guys making little tweaks like this to
code that simply has the wrong design, or wastes gobs of cycles because
of the wrong data structure, or something like that. The worst case I
ever saw was one programmer who was fiddling with her C code to speed
up an app that spent 30 hours in the database and mere minutes in the
CPU (no, I'm not kidding). Our DBA rewrote her SQL queries and got the
program down to 30 minutes (again, no exaggeration). There's a simple
lesson here: the big gains in execution speed do not come from tweaking
C# code. At least, not most of the time.

....and don't get me started about people (including, inexplicably,
Microsoft) who feel this urge to use structs instead of classes for
things like customer records because "structs have less overhead".
Grrr.... :)
 
Although I agree with some other which has posted reply that,
one should not waste time and effort in trying to micro-optimise code this
way,
personally, I still feel that for academic purpose, one has to know the
difference of each method.
 
Altramagnus said:
Although I agree with some other which has posted reply that, one
should not waste time and effort in trying to micro-optimise code
this way, personally, I still feel that for academic purpose, one has
to know the difference of each method.
Click to expand...

I think it's very occasionally helpful to know the difference, but I
don't think developers really *need* to know. After all, if you're
going to include it for this kind of thing, where do you draw the line?
Do you think everyone should know the difference between:

public class Test
{
static int x;

static
{
x = 5;
}

// Other stuff
}

and

public class Test
{
static int x = 5;

// Other stuff
}

?

How about whether it's faster to call Convert.ToInt32(string) or
Int32.Parse(string)?

You can spend far too long learning tiny bits of trivia which you never
need to know rather than learning these things as and when you need to
- i.e. when you've already found that there's a bottleneck which
involves that code.
 
Back
Top