Home All Groups Group Topic Archive Search About

Re: What .NET classes are SLOW vs. API?

Author
14 Oct 2006 8:02 PM
teslar91
Update and clarification:

..GetFiles appears to retrieve *only* the names, and stores them in the
..FileInfo array it returns.  Each call to .FileInfo to get
size/dates/attribs appears to result in a *separate* and time-consuming
call down to the API to get this information.

Compare that to the API call I'm using, which returns
name/size/dates/attribs all at once.

If you only need the names, the speed of the .NET method and API method
are nearly identical.  But if you need all the file properties, the API
method I've described is much faster, as I've demonstrated.

This should explain why some people are seeing good results with the
..NET method and I was not, and help you decide if using the API will be
an advantage in your situation.

Author
15 Oct 2006 3:13 PM
Cor Ligthert [MVP]
But don't complain if your dotnet program will not work anymore in future
because there has been an OS change.

Cor

<tesla***@hotmail.com> schreef in bericht
Show quoteHide quote
news:1160856171.306999.287360@k70g2000cwa.googlegroups.com...
> Update and clarification:
>
> .GetFiles appears to retrieve *only* the names, and stores them in the
> .FileInfo array it returns.  Each call to .FileInfo to get
> size/dates/attribs appears to result in a *separate* and time-consuming
> call down to the API to get this information.
>
> Compare that to the API call I'm using, which returns
> name/size/dates/attribs all at once.
>
> If you only need the names, the speed of the .NET method and API method
> are nearly identical.  But if you need all the file properties, the API
> method I've described is much faster, as I've demonstrated.
>
> This should explain why some people are seeing good results with the
> .NET method and I was not, and help you decide if using the API will be
> an advantage in your situation.
>
Author
15 Oct 2006 9:07 PM
Michael D. Ober
Since the FindFirstFile/FindNextFile OS calls have only seen changes based
on the size of a machine pointer since Windows 3.1, I suspect that other
than machine pointer size changes, any code will still be valid on 64 and
even 128 bit versions of Windows.  The real issue here is that using API
calls should always be encapsulated so that the if there is a change in the
future, it will be easy to find and update the API code.  In addition, using
"current" API header files will even eliminate this issue when it comes to
recompiling.
Mike Ober.

Show quoteHide quote
"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:uVvk4wG8GHA.2248@TK2MSFTNGP04.phx.gbl...
> But don't complain if your dotnet program will not work anymore in future
> because there has been an OS change.
>
> Cor
>
> <tesla***@hotmail.com> schreef in bericht
> news:1160856171.306999.287360@k70g2000cwa.googlegroups.com...
> > Update and clarification:
> >
> > .GetFiles appears to retrieve *only* the names, and stores them in the
> > .FileInfo array it returns.  Each call to .FileInfo to get
> > size/dates/attribs appears to result in a *separate* and time-consuming
> > call down to the API to get this information.
> >
> > Compare that to the API call I'm using, which returns
> > name/size/dates/attribs all at once.
> >
> > If you only need the names, the speed of the .NET method and API method
> > are nearly identical.  But if you need all the file properties, the API
> > method I've described is much faster, as I've demonstrated.
> >
> > This should explain why some people are seeing good results with the
> > .NET method and I was not, and help you decide if using the API will be
> > an advantage in your situation.
> >
>
>
>
Author
17 Oct 2006 1:19 AM
teslar91
Cor Ligthert [MVP] wrote:
> But don't complain if your dotnet program will not work anymore in future
> because there has been an OS change.

Ah, dear Cor.  The MVP that I will always remember as the one who
responded to a plea for help with sample code that not only failed to
address the problem, but actually insulted the user when it was run.

Do you know for a fact this will no longer work in Vista?  Do you have
a reasonable suspicion?  If so, why not say that?  Or are you really
just entertaining yourself by trying to put the fear of MS into people
who do things a different way than you?

"Oh lord Gates, hear me for I have sinned; I have made a dark pact with
the API for vastly superior performance, when thou hast said that the
..NET Framework is holy and thou shalt have no other calls before it!"

You've heard of encapsulation, right?  Good.  And I know you want to
feel special, but so have I.  My API calls are wrapped in a single
class library.  Heck, I even wrap some of my .NET Framework calls.  A
bit ironic, considering that a large part of the Framework is already a
wrapper; but it's a wrapper that changes when and how *MS* wants, not
*me*.

No matter whether you use API or .NET Framework, everything changes
sooner or later, and MS can break your code or kill your performance
with .NET Framework 3.0, Vista, SpongeBob SquareOOP, or whatever else
they dream up next.
Author
17 Oct 2006 3:31 AM
frogman7
Good word brother... Preach it

but here is another post somewhat on the same page some of the code may
help.

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/browse_thread/thread/f19f6e120d2f8a19?hl=en
Author
17 Oct 2006 4:31 AM
Cor Ligthert [MVP]
Not word any other response than this yyIyy

Cor

<tesla***@hotmail.com> schreef in bericht
Show quoteHide quote
news:1161047960.334837.160660@e3g2000cwe.googlegroups.com...
> Cor Ligthert [MVP] wrote:
>> But don't complain if your dotnet program will not work anymore in future
>> because there has been an OS change.
>
> Ah, dear Cor.  The MVP that I will always remember as the one who
> responded to a plea for help with sample code that not only failed to
> address the problem, but actually insulted the user when it was run.
>
> Do you know for a fact this will no longer work in Vista?  Do you have
> a reasonable suspicion?  If so, why not say that?  Or are you really
> just entertaining yourself by trying to put the fear of MS into people
> who do things a different way than you?
>
> "Oh lord Gates, hear me for I have sinned; I have made a dark pact with
> the API for vastly superior performance, when thou hast said that the
> .NET Framework is holy and thou shalt have no other calls before it!"
>
> You've heard of encapsulation, right?  Good.  And I know you want to
> feel special, but so have I.  My API calls are wrapped in a single
> class library.  Heck, I even wrap some of my .NET Framework calls.  A
> bit ironic, considering that a large part of the Framework is already a
> wrapper; but it's a wrapper that changes when and how *MS* wants, not
> *me*.
>
> No matter whether you use API or .NET Framework, everything changes
> sooner or later, and MS can break your code or kill your performance
> with .NET Framework 3.0, Vista, SpongeBob SquareOOP, or whatever else
> they dream up next.
>