Re: Performance issue (bug?) with .NET 2 ListView

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



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;
}
}









.



Relevant Pages

  • Re: Improving String.equals() implementation
    ... I don't understand your objection. ... The second method should catch the exception and return 'false'. ... If one is considering an optimization for a project, one cannot consider "optimizations" that break contract behavior. ... It is true that one of the equals() methods in my code ...
    (comp.lang.java.programmer)
  • Re: Delegates and Events confusion
    ... we find that the the Equals() method has been ... The publisher goes looking for a delegate that it is holding that is equal ... > wasn't storing an internal reference to the subscriber. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Equals
    ... Theorically equals should be a symetrical operation (docs state among ... >> However if either the objects are null as an exception will be thrown ... vtable for null instances of Foo: ... Bar = Object.ThrowNullException ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Comparing delegates
    ... A delegate is actually an instance of the Delegate class, ... function pointer in C or C++, but not really at all like a function pointer. ... Multicast delegate. ... This comparison can be made using the instance method Equals, ...
    (microsoft.public.dotnet.framework)
  • Re: annoying problem with Character
    ... In general, "fail fast" approach is a good thing, but in case of ... equals() it's not a normal practice to throw exception when the type is ... should throw exception when type is ...
    (comp.lang.java.gui)