>I have not seen this "abysmal" performance you are referring to. For example, I developed one form that had 6-8 look-up combos and 6 tx tables. Basically what you had was a series of parent, child, grand-child, and great-grand-child relationships (all managed with dataclas.net). Just to get the data, there is at least 12 trips to the server. I found the screen refreshes to be as good as Fox - or VB 6 for that matter. IMO, this was the mother of all screens as it showed a lot of data for "at a glance efficiency". If winforms had an inherent performance problem, I would suspect that problem would have been manifested in this screen.
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.
I have several forms that are reasonably complex (about 50 fields plus labels) etc. and I can see the form rendering when it starts up. It doesn't just snap in.
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).
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 would modify this to say that VFP's strength is its *integrated* local engine - assuming you are building what could be classified as a monolithic application. As you break your app apart into components, this integrated local data engine loses its effacacy. In terms of performance, ADO .NET performs extremely well.
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.
>Again, I have not seen the performance degradation you have seen with Winforms. I see that you have drawn a distinction between start-up (which is a one time issue) and the running of the app. In your opinion, what do you think is happening at startup. FWIW, based on all the advantages you enumerate re: .net - a slight hitch at startup - assuming it is there - seems like a small price to pay.
Ah, but I think that's not the right way to look at it. Perf can be slow for quite a while in the app. It's worst during startup but the problem is that everything is JIT compiled on the fly. Memory usage goes sky high because of this too as the compiler is actually part of your application. A WinForm app that does anything typiucally runs around 15 megs at startup, more if you dump a few controls on a form. This memory can be reclaimed later, but it's there to start with.
Case in point - I've built some utility tools that work very well. But i have had a ton of people tell me that they can't understand why the application is such a pig (this is Web Monitor) sucking system resources and the UI being slow and flickery. This is a real issue.
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 have number of things that I could move to .Net but have not because of this lack of an intermediate engine, something that installs easily and doesn't require a sys admin, but still provides rudimentary database functionality and locking rudimentaries. Third party tools are available but this is something that really lacks in .Net.
