>>
>Startup speed is the biggest issue. If .Net was not previously loaded and you start up a WinForm application you will sit and wait for 5 seconds before anything happens. For a commerical app this is a killer.
>>
>
>C'mon Rick.... Ever time how long it takes for Outlook, Word, Excel, etc. to start? How about tools like Goldmine, QuickBooks?? Even Fox can take about 4 seconds before you can actually get the command window. I think you are being a tad unrealistic here.

Outlook takes way less time to start than a first run .Net app. And Outlook is among the slowest, but at least it has reason to be since there 100megs worth of messages being accessed.

I look at this in relative terms not specific time terms because obviously the machine will have an effect on this.

>I started out with SharpUi on that app and that was terrible - with the form even under the best of circumstances takeing almost 5 seconds to load. Since I switched to Sandbar things look much better but still. I have several simpler forms that have roughly the same behavior though. The comparision in this case is almost one to one. Same exact UI (VFP using ActiveX controls - .Net using native controls).
>>
>
>I have not seen seen accross the board - 5 second start up times for forms - even complex ones.
>
>
>>
>There's no way that you're getting the same UI perf as VB6. VB6 was lightening fast with UI stuff especially load time (presumably because the OS somehow preloads the VBRuntime)...
>>
>
>I'll share some data with you off-line.... But in general, be careful with conclusory statements like "no way" - unless you are 100% familar with the circumstances.

With the current builds - yes I'm confident that there is NO WAY that you get an identical form to come up as fast with .Net as VB6.

This may change in the future as the IL code gets closer to machine code etc. but for now startup time of .Net apps has overhead of loading hte CLR into a process and compiling code when it starts up. You cannot get rid of that overhead (well the compile you can with precompiling with ngen but that doesn't solve all that much).

If you don't think this is such a big deal why do you think that for the longest time shrink wrap applications have been built with C++ and MFC for the most part? The reason is performance for the most part. Nodbody wants a sluggish UI...

This may take care of itself in 5 years when we get a nother major CPU power boost but right now the software is ahead of the hardware in terms of laoding.

>
>
>>
>Depends on what you talk about. ADO.Net sucks big time with large numbers of records because it loads everything into memory.
>>
>
>>
>Try running a report that pulls in 100,000 records and sit back and wait for the data to be loaded into memory. ADO.Net was not build for large amounts of data pulled to the client. Microsoft has admitted as much in saying that much over 1000 rows is not an optimized scenario. While it's true that you should avoid pulling so much data all at once some scenarios (like reporting for example) require it.
>>
>For smaller amounts of data, though ADO.Net performs very well.
>>
>
>All good points...but what % of the time does one have to deal with 100K record report?

Not very often, but what do you do when you need it? This is what Steve B. talks about - that factor in your app where there's a breaking point that will be very diffuclt to work around. I've seen this with several developers and I personally don't want to be the one that they point the finger at and say - this is unacceptable performance - fix it or we'll sue!

All it takes is one case!

And you'll have this issue ESPECIALLY with people switching from Fox because they are used to getting a consistent performance curve (to a point).

>The other issue I see (and for me this is a big one) is that to build shrink wrap product .Net lacks a small data solution. If you sell to the personal market or even small business market you cannot expect to use SQL Server/MSDE. There's no local data solution. It's either you use local as in XML only or you use SQL Server - nothing in between.
>>
>
>I agree, shrink-wrapped apps is a yet to be resolved issue.


+++ Rick --