What .NET classes are SLOW vs. API?

11 Oct 2006 6:36 PM

teslar91

As a fairly new .NET coder, I would greatly appreciate some comments on
any .NET classes that are known to be notoriously slow by comparison to
direct API calls.

I've already had a bad experience with System.IO.DirectoryInfo. My
requirements were to recursively scan a folder, recording all
filenames/dates/sizes/attribs. The target folder contained 88,000
files and 5,000 subfolders.

I originally used System.IO.DirectoryInfo and found it incredibly slow,
so I tried the same thing with API FindFirst/FindNext. The API version
was *eighteen* times faster when run from the IDE, and *five* times
faster when running the Release .exe. Tests were run multiple times to
make sure the directories were cached, thus disk access times were not
a factor.

This was unacceptible for my application, so I'm writing a nice class
for directory listings using the API which kicks
System.IO.DirectoryInfo's arse.

However, I would prefer to avoid needless
write/wtf/rewrite/benchmark/fix cycles in the future if the kindness of
strangers can steer me clear. :) I'm only interested in classes that
are likely to be called rapidly and repeatedly, and are much slower
than API equivalents; and so are likely to have a large impact on
application performance.

12 Oct 2006 2:07 PM

Patrick Steele

In article <1160591762.265456.240***@i42g2000cwa.googlegroups.com>,
tesla***@hotmail.com says...

> However, I would prefer to avoid needless
> write/wtf/rewrite/benchmark/fix cycles in the future if the kindness of
> strangers can steer me clear. :) I'm only interested in classes that
> are likely to be called rapidly and repeatedly, and are much slower
> than API equivalents; and so are likely to have a large impact on
> application performance.

I think that's an "it depends" question. I've used the DirectoryInfo
class to recurse into a directory and it worked quite fast. However, the
directory didn't contain 88,000 files and 5,000 subdirectories. If
you're going to be processing that kind of a data set and want it to run
as fast as possible, you're probably going to need to use unmanaged
code.

I've done some custom drawing with .NET using System.Drawing and the
Grpahics object. It was pretty easy and the performance for the
application was very acceptable. But -- if I wanted to write the next
'Battlefield 2142', I wouldn't use the System.Drawing namespace... :)

--
Patrick Steele
http://weblogs.asp.net/psteele

12 Oct 2006 3:07 PM

teslar91

Patrick Steele wrote:

> I think that's an "it depends" question. I've used the DirectoryInfo
> class to recurse into a directory and it worked quite fast. However, the
> directory didn't contain 88,000 files and 5,000 subdirectories. If
> you're going to be processing that kind of a data set and want it to run
> as fast as possible, you're probably going to need to use unmanaged
> code.
>
> I've done some custom drawing with .NET using System.Drawing and the
> Grpahics object. It was pretty easy and the performance for the
> application was very acceptable. But -- if I wanted to write the next
> 'Battlefield 2142', I wouldn't use the System.Drawing namespace... :)

True. :) For the next "Battlefield 2142", even 25% slower drawing
would be a killer. And my need for massive directory scans is also
rather unusual.

I guess what I'm getting at, is that I expect *all* managed code to be
somewhat slower than unmanaged code. But when something is 5-10 times
slower, especially when it's essentially just a wrapper around an API
call, that suggests a flaw in the underlying code. And that's the kind
of thing I'd rather like to know about in advance.

Another prime example I've found is the speed of DataGridView being
much worse than the older DataGrid. People have commented that they
can actually see it repainting individual rows on high-end systems. I
tried it, and perhaps that's a slight exaggeration, but it is indeed
SLOW. I saw a post on the MS bug forums where a MS Rep actually said
that yes, it *is* a bug, it's calling slow RenderText instead of fast
DrawText (or something like that), and they didn't intend to do that.
However, they're not going to fix it, because someone might have
written extensions to the DataGridView that *rely* on it calling
RenderText, and they don't want to break anyone's code! Fair enough,
but I'm steering clear of DataGridView when possible since I know what
the deal is...

16 Oct 2006 2:14 PM

Chris Dunaway

tesla***@hotmail.com wrote:

> True. :) For the next "Battlefield 2142", even 25% slower drawing
> would be a killer. And my need for massive directory scans is also
> rather unusual.

My question is Off Topic, but are you writing something to assist with
Battlefield modding? I have been looking for specs for the BF1942 .rfa
file, especially information regarding the compression they use to pack
the files, and have not been able to find anything.

Do you perchance have any information on that?

Thanks,

Chris