Re: Performance issue (bug?) with .NET 2 ListView
- From: "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 31 May 2006 12:50:37 -0400
Ok, I see what you are saying, yes, it will delegate to Equals, but
ultimately, the first check in the Equals overload is against the length.
It might be a few more IL statements, but I don't know how much exactly.
In the end, it's a moot point, since the readability aspect definitely
makes it more attractive.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Lebesgue" <lebesgue@xxxxxxxxx> wrote in message
news:enOeLBNhGHA.4864@xxxxxxxxxxxxxxxxxxxxxxx
Nicholas,
While I understand that == call is delegated to Equals, which checks
for string length equality in the first place, which has basically the
same effect as IsNullOrEmpty call, according to FxCop rules, it yields
execution of significantly more MSIL instructions, thus should be avoided
to achieve the best peformance [1].
I believe the difference would be very subtle - but there certainly is
some, when it's listed as FxCop rule.
[1] FxCop Documentation 1.312.0:
http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.35&url=/Performance/TestForEmptyStringsUsingStringLength.html
"Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:O23II2MhGHA.1612@xxxxxxxxxxxxxxxxxxxxxxx
Lebesgue,
While I agree that IsNullOrEmpty does improve readability, I fail to
see how it is an improvement to performance. The code is pretty much the
same in the IsNullOrEmpty method and what is being done here.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Lebesgue" <lebesgue@xxxxxxxxx> wrote in message
news:eBKjIVMhGHA.3756@xxxxxxxxxxxxxxxxxxxxxxx
Just a quick note - for performance and also readability reasons, you
should use string.IsNullOrEmpty() instead of checking for null and
string.Empty equality.
<mrshrinkray@xxxxxxxxxxxxxx> wrote in message
news:1149087063.163264.240010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Chris Dunaway wrote:
Just a thought:
Do you have any try catches that might be swallowing an exception?
Perhaps an exception is being generated and swallowed.
Spot on! For some reason the following code:
private int ConvertToInt(string input)
{
if ( input != null && input != "" )
{
try
{
int retvalue = Convert.ToInt32(input);
return retvalue;
}
catch
{
return 0;
}
}
else
{
return 0;
}
}
was slowing down the application hugely ("A first chance exception of
System.FormatException was caught") in .NET 2.0 but not 1.1. This might
be the debugger, I didn't check. Anyway as I'm using 2.0 I just changed
the above method to:
private int ConvertToInt(string input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(input, out result);
return result;
}
else
{
return 0;
}
}
.
- References:
- Performance issue (bug?) with .NET 2 ListView
- From: mrshrinkray@xxxxxxxxxxxxxx
- Re: Performance issue (bug?) with .NET 2 ListView
- From: cody
- Re: Performance issue (bug?) with .NET 2 ListView
- From: mrshrinkray@xxxxxxxxxxxxxx
- Re: Performance issue (bug?) with .NET 2 ListView
- From: mrshrinkray@xxxxxxxxxxxxxx
- Re: Performance issue (bug?) with .NET 2 ListView
- From: Chris Dunaway
- Re: Performance issue (bug?) with .NET 2 ListView
- From: mrshrinkray@xxxxxxxxxxxxxx
- Re: Performance issue (bug?) with .NET 2 ListView
- From: Lebesgue
- Re: Performance issue (bug?) with .NET 2 ListView
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Performance issue (bug?) with .NET 2 ListView
- From: Lebesgue
- Performance issue (bug?) with .NET 2 ListView
- Prev by Date: Re: Encoding string for xml
- Next by Date: Re: dealing with unsigned char* from C++ .lib
- Previous by thread: Re: Performance issue (bug?) with .NET 2 ListView
- Next by thread: Re: Performance issue (bug?) with .NET 2 ListView
- Index(es):
Relevant Pages
|