Performance issue (bug?) with .NET 2 ListView

[mrshrinkray]

Are there any know bugs with the ListView in .NET 2? I'm having
problems with an application that takes 15 seconds in 1.1, and now
takes over a minute. The code in question uses:

listViewItem = this.listView1. Items.Add(...)

followed by 7 calls to

listViewItem.Su bItems.Add(...)

When I comment out this code, the application runs in the same time as
the 1.1 version.

Any suggestions? I can provide the source code if required.

[mrshrinkray]

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(st ring 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.FormatEx ception 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(st ring input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(in put, out result);
return result;
}
else
{
return 0;
}
}

[Lebesgue]

Just a quick note - for performance and also readability reasons, you should
use string.IsNullOr Empty() instead of checking for null and string.Empty
equality.

<mr*********@go oglemail.com> wrote in message
news:11******** **************@ c74g2000cwc.goo glegroups.com.. .

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(st ring 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.FormatEx ception 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(st ring input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(in put, out result);
return result;
}
else
{
return 0;
}
}

[Marc Gravell]

Most likely this was the debugger, then; exceptions are actually damned
fast - but the IDE makes 'em look slow.

You may also be able to simplify this to:

private int ConvertToInt32( string input) {
int result;
int.TryParse(in put, out result); // discard returned bool
return result;
}

(I also hacked the name just to be pedantic with the CLR guidelines - but
since this method is private it is purely academic)

Marc

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard. caspershouse.co m

"Lebesgue" <le******@gmail .com> wrote in message
news:eB******** ******@TK2MSFTN GP02.phx.gbl...

Just a quick note - for performance and also readability reasons, you
should use string.IsNullOr Empty() instead of checking for null and
string.Empty equality.

<mr*********@go oglemail.com> wrote in message
news:11******** **************@ c74g2000cwc.goo glegroups.com.. .

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(st ring 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.FormatEx ception 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(st ring input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(in put, out result);
return result;
}
else
{
return 0;
}
}

[Lebesgue]

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/...ingLength.html
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:O2******** ******@TK2MSFTN GP04.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Lebesgue" <le******@gmail .com> wrote in message
news:eB******** ******@TK2MSFTN GP02.phx.gbl...

Just a quick note - for performance and also readability reasons, you
should use string.IsNullOr Empty() instead of checking for null and
string.Empty equality.

<mr*********@go oglemail.com> wrote in message
news:11******** **************@ c74g2000cwc.goo glegroups.com.. .

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(st ring 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.FormatEx ception 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(st ring input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(in put, out result);
return result;
}
else
{
return 0;
}
}

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard. caspershouse.co m

"Lebesgue" <le******@gmail .com> wrote in message
news:en******** ******@TK2MSFTN GP03.phx.gbl...

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/...ingLength.html
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote
in message news:O2******** ******@TK2MSFTN GP04.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Lebesgue" <le******@gmail .com> wrote in message
news:eB******** ******@TK2MSFTN GP02.phx.gbl...

Just a quick note - for performance and also readability reasons, you
should use string.IsNullOr Empty() instead of checking for null and
string.Empty equality.

<mr*********@go oglemail.com> wrote in message
news:11******** **************@ c74g2000cwc.goo glegroups.com.. .
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(st ring 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.FormatEx ception 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(st ring input)
{
if ( input != null && input != "" )
{
int result = 0;
int.TryParse(in put, out result);
return result;
}
else
{
return 0;
}
}

[mrshrinkray]

So can anyone shed light here on why the ConvertToInt was taking .NET
2.0 so much longer to run than 1.1? Is it the changes to the VS.NET
debugger? Or something in the framework?

[mrshrinkray]

Well, the saga continues. The problem was being veiled by the
ConvertToInt inside the business logic part of the code. I have now
added:
Application.Ena bleVisualStyles ();

inside Main. This is actually the source of my problem. Remove it and
the application runs the same speed as the .NET 1.1. Include it and it
runs 4x as slow.

Source code is at:
http://www.google.com/url?sa=D&q=htt...1-dbe878a161b7

If anyone can spare 5 mins to try running it on .NET 1.1 and .NET 2.0,
and add Application.Ena bleVisualStyles (); to Main() and see if they get
the same speed difference. Use testlog.log as the example log.

[Marcus Andrén]

On 31 May 2006 05:59:54 -0700, "mr*********@go oglemail.com"
<mr*********@go oglemail.com> wrote:

It's over 6000 items I'm adding, here's a snippet:

If you are adding 6000 items I really recommend that you use AddRange.
It is significantly (several times) faster than Add when dealing with
large numbers of items. I don't usually use SubItems.Add, but instead
use the constructor that takes a string array.

Here is a some code (slightly modified for simplicity) from one of my
applications that has a ListView with about 10000 items. It takes
about a second to fill it.
private void FillListView()
{
listView.BeginU pdate();
listView.Items. Clear();

//We add to a List(Array) first because AddRange is a lot faster
//than Add when dealing with lots of elements in ListView
//Also, we don't seem to have to turn off the sorter when adding
//all the elements at once

List<ListViewIt em> items = new List<ListViewIt em>();
foreach (Episode episode in episodes)
items.Add(Creat eEpisodeListVie wItem(episode)) ;

listView.Items. AddRange(items. ToArray());

listView.EndUpd ate();
}

private static ListViewItem CreateEpisodeLi stViewItem(Epis ode
episode)
{
ListViewItem item = new ListViewItem(
new string[]
{
episode.Origina lAirdate.HasVal ue?
episode.Origina lAirdate.Value. ToShortDateStri ng():"",
episode.Show.Na me,
episode.Season. ToString(),
episode.Episode Number.ToString (),
episode.Title
});
item.Tag = episode;
return item;
}

--
Marcus Andrén