.NET Forum / .NET Framework / General / May 2006
Why are .Net UIs slower than C++ or classic VB?
|
|
Thread rating:  |
Jim Hubbard - 01 May 2006 09:59 GMT I've noticed (for quite some time now) that .Net UIs are not as responsive (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton Antivirus or even the .Net version of Paint done by Washington University vs good old Paint UIs for examples).
They are also not as professional looking as the older applications and the reaction times of the UIs is not professional looking at all.
Why do you think this is? Is it bad programming or is there something else going on here?
Cor Ligthert [MVP] - 01 May 2006 10:28 GMT For those who want to answer this,
Maybe it is right to read this thread first.
http://groups.google.com/group/microsoft.public.dotnet.general/browse_frm/thread /a7b4d6bfe03316f6/028eada042806d5a#028eada042806d5a
Cor
Jim Hubbard - 01 May 2006 11:23 GMT Especially this one.....
http://groups.google.com/group/microsoft.public.dotnet.general/browse_frm/thread /a7b4d6bfe03316f6/028eada042806d5a#028eada042806d5a
Jim
> For those who want to answer this, > [quoted text clipped - 3 lines] > > Cor Jim Hubbard - 01 May 2006 12:22 GMT Cor,
Perhaps you missed it the firat time, so here is a link for you.
http://groups.google.com/group/microsoft.public.dotnet.languages.vb/msg/cca0711d 1dc4e3d2?as_umsgid=KPo%25f.514$oW1.47@bignews1.bellsouth.net)
If anything in the post is unclear, please let me know and I will try and expain it further for you.
Thanks! Jim
> For those who want to answer this, > [quoted text clipped - 3 lines] > > Cor Barry Kelly - 01 May 2006 11:27 GMT > I've noticed (for quite some time now) that .Net UIs are not as responsive > (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton [quoted text clipped - 6 lines] > Why do you think this is? Is it bad programming or is there something else > going on here? I agree. I think (and hope) it's a lot to do with GDI+ not being accelerated (and it probably will never be, as WPF approaches). Something I've especially noticed is that resize logic for forms with lots of nested containers is especially expensive. Very laggy resizing of 16 or so nested containers of different kinds shouldn't slow a 3GHz machine to a crawl, but it can and does!
-- Barry
Jim Hubbard - 01 May 2006 14:19 GMT >> I've noticed (for quite some time now) that .Net UIs are not as >> responsive [quoted text clipped - 19 lines] > > -- Barry The new Windows Presentation Foundation stuff looks much better than the UI stuff we currently have for .Net.
Take a look at the demos for Windows Expression at http://www.microsoft.com/products/expression/en/default.mspx. In the demos, the UIs look fast and smooth. Not at all jerky or slow!
It's at the core of Vista's new look and is promised as an upgrade for XP and 2003 Servers.
Just wish we had it now.....I'd hate to think I have to redo these apps all over again a year (or so) from now.
Jim
Greg Young - 01 May 2006 16:08 GMT > The new Windows Presentation Foundation stuff looks much better than the > UI stuff we currently have for .Net. > > It's at the core of Vista's new look and is promised as an upgrade for XP > and 2003 Servers. You are right Jim!
> Just wish we had it now.....I'd hate to think I have to redo these apps > all over again a year (or so) from now. Thats why we tier apps right?
Cheers,
Greg
>>> I've noticed (for quite some time now) that .Net UIs are not as >>> responsive [quoted text clipped - 34 lines] > > Jim JasonS - 01 May 2006 11:35 GMT Well, I see two points of interest in this posting.
Firstly, some aspects of .NET display handling are slower, but I am more then happy to occasionally sacrifice performance for the visual inheritance that the .NET model gives me. No more days scouring sites for third-party controls that have exactly the bizarre combinations of features, followed by weeks of begging them to add the other features we require. Ah, blessed relief.
The second point is that you seem to be trolling the newsgroups posting inflammatory comments, for what reason I'm not sure, but I guess that you feel any publicity is good publicity :)
I would suggest that anyone wanting to follow your line of argument use Google to investigate the terabytes of newsgroup comments from VB6 developers between about 2002 and 2004, and leave this group free for genuine questions and discussions.
Cheers, Jason
> I've noticed (for quite some time now) that .Net UIs are not as responsive > (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton [quoted text clipped - 6 lines] > Why do you think this is? Is it bad programming or is there something else > going on here? Jim Hubbard - 01 May 2006 12:14 GMT > Well, I see two points of interest in this posting. > [quoted text clipped - 5 lines] > by weeks of begging them to add the other features we require. Ah, blessed > relief. That's a good point. And, the object oriented nature certainly does allow for easily extending the simple UI controls available for .Net. But, I am asking about the UI slowness that I have seen in professionally designed and distributed .Net applications. I want to avoid that slowness if possible.
> The second point is that you seem to be trolling the newsgroups posting > inflammatory comments, for what reason I'm not sure, but I guess that you > feel any publicity is good publicity :) Hmmmm...... So, asking non-flattering questions is trolling? AFAIK, these applications could have been written poorly. Hence the question.
If there are specific programming techniques that make the .Net apps seem slow and kludgy, I want to know so that I can avoid those things. So do you know if it is due to programming technique or is it inherent in the .Net framework?
There is actually an argument that can be made that states that .Net UIs were made slower and more simplistic on purpose. It can most certianly be viewed as inflamatory by people not of an open mind to thoughts contrary to thier own. And, caring so deeply about your delicate nature, I would be hesitant to post it here.
> I would suggest that anyone wanting to follow your line of argument use > Google to investigate the terabytes of newsgroup comments from VB6 > developers between about 2002 and 2004, and leave this group free for > genuine questions and discussions. Questions about slow .Net UIs are not "genuine questions and discussions"? Really?
Interesting...although I'm sure some of the more open-minded programmers here would disagree.
Generally, I have found the members of this discussion group to be extremely open-minded, willing to discuss .Net shortcomings (as well as its accomplishments) and willing to help others avoid common programming errors that may result in diminished performance in your .Net applications.
Jim
Patrice - 02 May 2006 14:39 GMT So instead of starting a general discussion, IMO your best bet would be rather to tell us what you have done that it slow so that one could attempt to make suggestions to avoid this...
If not already done, you could start with UI code only and see how it performs, post slow parts etc...
 Signature Patrice
>> Well, I see two points of interest in this posting. >> [quoted text clipped - 49 lines] > > Jim Jim Hubbard - 02 May 2006 16:14 GMT As I said in my post, there are several professional applications that you can see this in.
I was (still am) wondering if this was due to sloppy programming on their part or was it due to the slowness of the .Net UI.
If you have any ideas about this, I'd love to hear them.
> So instead of starting a general discussion, IMO your best bet would be > rather to tell us what you have done that it slow so that one could [quoted text clipped - 59 lines] >> >> Jim Patrice - 03 May 2006 15:59 GMT What do you want to do about those applications ?
You could try to decompile them if you wish but IMO it would be likely more usefull to see this on your own real world example on which you have control so it can be tested/changed. Else it will just raise IMO a general useless discussion....
As .NET uses interop it is likely of outmost importance to minimize useless calls (incidentally I'm coming accross an external application that refresh 4 times the same grid when it loads). Also you could try tricks such as SuspendLayout/ResumeLayout or even hiding controls while you are intensively updating them...
 Signature Patrice
> As I said in my post, there are several professional applications that you > can see this in. [quoted text clipped - 68 lines] >>> >>> Jim Frans Bouma [C# MVP] - 03 May 2006 09:46 GMT > So instead of starting a general discussion, IMO your best bet would > be rather to tell us what you have done that it slow so that one > could attempt to make suggestions to avoid this... > > If not already done, you could start with UI code only and see how it > performs, post slow parts etc... .NET GUI's are dead slow, period. I have a form with several tabs and grids. When I resize it, it whobbles and is in all aspects very slow. I profiled the crap out of it, and every profiler comes up with core .NET slowness. I can't do a thing about it to make it faster. When I check out VB6 forms, they perform a lot faster, I can't lie about that, it's true.
That said, I also firmly think that winforms was a mistake. There are simply too many issues with the winforms code. I hope WPF solves it, though that's still far away and it will have its own list of incompatibilities...
FB
 Signature ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
Jim Hubbard - 04 May 2006 05:25 GMT >> So instead of starting a general discussion, IMO your best bet would >> be rather to tell us what you have done that it slow so that one [quoted text clipped - 14 lines] > though that's still far away and it will have its own list of > incompatibilities... And, it is certainly no shame that a company (ANY company - even Microsoft) makes mistakes. You always make mistakes. Success is what is left after you toss out all of the mistakes. There's no shame in that.
The shame is when they cannot admit those mistakes (to themselves and their customers), learn from them and move forward wiser and stronger than they were before (with greater customer confidence and backing than before).
Even worse, they seem to simply try and hide one layer of mistakes with yet another layer - instead of ripping out the weak parts and re-tooling the layer. The silliest thing is that Microsoft seems to try and hide it's obvious mistakes from programmers no less. How bizarre.....
Believe it or not, mistakes are how we grow. When we learned to walk, we tried to balance and fell on our bums many times before we got it right. But, nobody ever ignored the fact that we fell down, they simply applauded when we got back up.
Although it may not seem like it, I am a fan of Microsoft. As a loyal fan, I believe that I do Microsoft a dis-service by NOT calling them out on things that are just plain wrong. I want them to admit their mistakes - to foster trust between the company and its clients and customers. I want it to learn from its mistakes - because I want better tools and a better desktop. And, I want a company that listens to its customers and follows what THEY want....not what IT wants.
While I am chomping at the bit to try WPF, right now .Net reminds me of "The 11 Pound Pencil". If you've never heard of "The 11 Pound Pencil" you should read it at http://www.mobilityguru.com/2006/03/05/who_designed_this_crap/ .
Jim
Barry Kelly - 01 May 2006 20:18 GMT > Firstly, some aspects of .NET display handling are slower, but I am more > then happy to occasionally sacrifice performance for the visual inheritance > that the .NET model gives me. I come from a Delphi background. I've had visual inheritance since about 1996, and the performance of my Delphi UIs (and I construct my .NET UIs the much the same way as those Delphi UIs) is better.
However, I'm not really willing to give up the benefits of C# 2.0 to use Delphi again, unless there's a compelling reason (such as a standalone executable, higher performance graphics or native unmanaged code needed for performance).
-- Barry
JasonS - 02 May 2006 13:43 GMT > I come from a Delphi background. I've had visual inheritance since about > 1996, and the performance of my Delphi UIs (and I construct my .NET UIs [quoted text clipped - 4 lines] > executable, higher performance graphics or native unmanaged code needed > for performance). I started using Delphi when it was first released, and I was delighted that something came out that was object oriented with a nice GUI environment, but Borland's original policy of charging 50 UK pounds for every technical support question (and their very limited supplied manuals) meant there was little likelihood of it being adopted at the banks I was working for, particularly given that MS support at that time was free.
Borland's UI handling has always been very slick, probably largely due to the fact most functions call the WinAPI directly without the overheads of the intermediate functions performed by .NET such as locale specific formatting, additional security features, visual 'theming' etc, which most of us don't use but it does make sense to provide.
I wonder what the performance of the new WinFX will be :/
Cheers, Jason
CMM - 03 May 2006 01:46 GMT I tend to agree with this post as well. Almost everything .NET does goes through several layers, probably even a thunk or two (to convert say some internal Long into a Win32 Int) until it finally reaches Win32... where of course it goes through a couple of rings.
I wonder if there are ways for video card manufacturers to hook into .NET to accelerate some things without waiting for the calls to reach Win32.... I guess this is was Vista is suppossed to address.
 Signature -C. Moya www.cmoya.com
> >> I come from a Delphi background. I've had visual inheritance since about [quoted text clipped - 24 lines] > Cheers, > Jason Mike Deakins - 01 May 2006 14:10 GMT One of the reason might be GDI+ performance is too poor. Drawing a SXGA bitmap using GDI+ takes 25ms on my computer.
 Signature Best Regards, Mike J. Deakins
> I've noticed (for quite some time now) that .Net UIs are not as responsive > (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton [quoted text clipped - 6 lines] > Why do you think this is? Is it bad programming or is there something > else going on here? Randolpho - 01 May 2006 16:08 GMT I very rarely get poor responsiveness on .NET software. I wonder if perhaps you're imagining things? If, however, there *is* poor performance on a .NET application, I would blame one of two people: either a) you are running .NET on a 486 sx 30 with 4 MB ram, or b) the programmer(s) didn't understand how to write Windows.Forms. In the case of Norton Antivirus, I'd say this is highly likely, as Norton has a history of writing bloated crap that ruins your computer and is harder to uninstall than most viruses.
Virii?
Frans Bouma [C# MVP] - 02 May 2006 10:03 GMT > I've noticed (for quite some time now) that .Net UIs are not as > responsive (see Franklin Covey's PlanPlus for Windows XP or [quoted text clipped - 6 lines] > Why do you think this is? Is it bad programming or is there > something else going on here? Winforms is synchronically, and Win32, which it is based on, is asynchronically. So, say you want to disable a button in .NET, you set button.Enabled to false, right? Well, under the hood, a message is send to the button, and there's a delay when that's handled, the feedback comes back that the message is handled and hte button is actually disabled. This is a lot of overhead.
For all the people who claim it's better in WPF: I'm sure it is, but that's still a long time away and it doesn't help the people today.
FB
 Signature ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
Jim Hubbard - 02 May 2006 16:25 GMT >> I've noticed (for quite some time now) that .Net UIs are not as >> responsive (see Franklin Covey's PlanPlus for Windows XP or [quoted text clipped - 13 lines] > comes back that the message is handled and hte button is actually > disabled. This is a lot of overhead. Yes it is.
It seems that Microsoft is simply adding layer upon layer to thier OS - which would explain the OS bloat and ever-increasing system requirements.
.Net is an answer to an OS problem anyway. The bufffer overflows that .Net was meant to handle should be taken care of by the OS....not the programming langauge and a runtime that lays on top of the OS.
Seems to me that Windows is long overdue for a complete rewrite from the ground up.
Sure, this would mean breaking backwards compatability with some of the older stuff, but they could include a personal copy of Virtual PC and allow the user to run his/her old apps under the old OS while adopting the new, slimmer, faster, more functional, Windows X and the new programming that it allows.
>For all the people who claim it's better in WPF: I'm sure it is, but > that's still a long time away and it doesn't help the people today. It's been 5 (IMHO miserable) years with .Net. Nothing really to show for the effort outside the enterprise (where competition is limited and comtrols are very tight).
.Net (IMHO) just isn't cutting it as the tool that the COMMUNITY uses to expand the OS (and that's what you need to build a great OS). It never should have been written and forced upon us. The problems with buffer overflows should have been fixed in the OS - then it wouldn't matter what tool you chose to write your code in.
But......whatever.......
Jim
AMDRIT - 02 May 2006 18:38 GMT A can of worms was opened with this thread, I believe the core context it is the next evolution in the C++ vs VB saga, and is continuing. Coupled into this thread is a reprised villainous assault towards another contributor tiring the conversation out right and taking from heart of the conversation.
It is what it is, and it is about trade-offs. C++ and VB are not dead, gone, or otherwise non-employable. Purists can still get the nominal performance gains back simply be implementing those tools. I do not believe that performance is all that penalized in the .Net framework and have several applications under my belt as proof of pudding.
That said, it is about trade-offs, and you trade raw performance with sophisticated simplicity, true connectedness, and commonality in form and function. Data binding in VB is a taboo thing, not all controls were data aware, and inheriting them was complex at best and kludgy at worst. API's were needed for threading and message handling, while most of the samples and documents were relegated to the world of C++. The C++ world had to write their event maps, use the APIs, decide on MFC, STL, ATL, SUV, ACLU and a few other TLA's, still pointer management was rough, workflow continues to elude even the veteran developer, and, ick, it's C++.
Enter the world of .Net. Nearly everything you want is there out of the box. Developers really only have to concentrate on their workflow, business logic and persistent data management. Additionally, it quelled the qualms and heated debates as to C++ and VB; they are now on an even playing field. For raw power, performance, and interoperability; stick with the unmanaged C++. For ritual, mundane UI development any of the C++, C#, and VB solutions will suffice in the implementation. All three can talk to one another without too much special consideration, a benefit and relief for anyone that survived the COM/DLL HELL days.
The UI components provided out of the box are consistent and complete. However; you are not tied to the implicit use of those controls including the winforms. While you have been provided the ability to have access to all events, messages and awareness, you may and can create your own set of UI components from the ground up inheriting right from System.Object. Synchronous/Asynchronous, bah who cares, if you don't like red kool-aid, try the purple.
You may be stuck with deploying the whole framework; however, you are not tied to the whole framework. And still, this conversation assumes that the performance hit is such that it bothers the user. ACT is an example of something funky going on in the .Net world; however I think it has more to do with data then the interface.
There are not a lot of commercial applications out there that I know of, that employ .Net. Those that are out there, I wonder about the teams that employ them, were they trying to stick to the old ways and not taking full advantage of the new features? What about the code base, was a direct port from earlier works or was it optimized and tweaked. Did they clean up disposable object, release resources? Just because it is in commercial release doesn't make it right, take a look at Windows ME's longevity and acceptance.
.Net is the necessary evil in my world. A development tool it not always the most technically proficient bearer of results. Why use .Net when Office will work? Why use .Net when windows scheduler will suffice? Why drink Bud Dry? All decisions are influenced by external sources and not always the right ones, why else would a normal human being pay thousands for a wiper blade for a government aircraft?
In an experiment, I have created a VB application and a VB.Net application. One form with one button each. The button launches five new instances of the form. Using tick count, the times appear very similar. What are specifically seems slow and sluggish in your application?
I am running out of steam, so I will close with this. Public ridicule chastising public ridicule discredits your ability to ask serious questions and weakens your perceived insight in future discussions, reiterating your contempt was just petty, childish and low.
I don't know Cor, but I know of his work and involvement in the community. Right or wrong, he and others are there to assist and help. They do so, and people are resolving their issues. Yes, he may be doctrinated and advocates his views in his responses, but doesn't a professor do the same when asked to impart his knowledge?
When a co-worker annoys you, do you say so publicly? When someone at Burger King steps on your toes, twice, do you make a loud rebuke? Professional courtesy says you debate the points, agree to disagree, or just keep quite. Common courtesy says you apologize for the terse, personal, and unwanted comments.
>>> I've noticed (for quite some time now) that .Net UIs are not as >>> responsive (see Franklin Covey's PlanPlus for Windows XP or [quoted text clipped - 48 lines] > > Jim CMM - 03 May 2006 00:57 GMT Despite being a fan of .NET (from a programmer-- ease of development standpoint) I tend to agree with almost everything you say. Windows is due for a big rewrite a la MacOS X.... I doubt MS has the guts to do it.
 Signature -C. Moya www.cmoya.com
>>> I've noticed (for quite some time now) that .Net UIs are not as >>> responsive (see Franklin Covey's PlanPlus for Windows XP or [quoted text clipped - 48 lines] > > Jim Jim Hubbard - 03 May 2006 01:07 GMT IF they ever did, it'd be interesting to see if they used .Net to write it. I don't think they can. You can't write an OS in entirely managed code - can you?
I'd love to see them put buffer overflow protection in the OS and keep the OOP (class designs and the core classes) of .Net while tossing the framework (i.e. IL code) idea. That should speed things up significantly.
Anyway, if they did a complete rewrite (slimming it down and speeding it up) it would definitely be something worth paying to upgrade to.
> Despite being a fan of .NET (from a programmer-- ease of development > standpoint) I tend to agree with almost everything you say. Windows is due [quoted text clipped - 52 lines] >> >> Jim CMM - 03 May 2006 01:39 GMT Well I doubt the kernel would be .NET ;-) .... but the .NET Framework should completely replace the Win32 API. And, I mean COMPLETELY.... not just a layer over it (that eventually calls down into Win32 for everything) the way its implemented now.
 Signature -C. Moya www.cmoya.com
> IF they ever did, it'd be interesting to see if they used .Net to write > it. I don't think they can. You can't write an OS in entirely managed [quoted text clipped - 64 lines] >>> >>> Jim Cor Ligthert [MVP] - 03 May 2006 06:06 GMT Carlos,
Almost from the first start of OS or DOS or Computer Management System whatever names this kind of things have had (The first computers had no OS), they have existed from layers. The reason for this is simple, by instance hardware changes should not have to influence the overall system, which was direct a problem after the first use of OS that did not exist from layers.
Therefore for me it is a very good approach that Net is one of those layers, they would be crazy to change that.
Problem is maybe that the last 20 years a lot of people are sticked to Microsoft Systems or other microprocessor driven systems and think that those are the only ones and use the names of those and are not able to think in wider use of computers.
Therefore in my opinion the Net should *not* replace the Win32 API, there should come API's which have a high flexibility to interact with Net; Net can than always be placed above those API's.
This cost of course time to see the results; you cannot get rid of Win32 in some years. I never have had any attention to how WinFX is build; however I assume that this normal way by creating a next generation OS will be the case.
Just my thought,
Cor
> Well I doubt the kernel would be .NET ;-) .... but the .NET Framework > should completely replace the Win32 API. And, I mean COMPLETELY.... not [quoted text clipped - 71 lines] >>>> >>>> Jim CMM - 03 May 2006 01:02 GMT VB Classic made brilliant use of light-weight (not "real"... as in not having hWnds) controls (The label, image, and shape controls) that were painted by the VB Runtime and not handled by the OS. In .NET everything has an underlying hWnd control underneath. These creates some "robustness" but also introduces some bad performance... hWnd controls really are "Windows".... they're created using the same API (CreateWindowEx) as "Forms" and when an app has too many of them it quickly degrades in performance.
 Signature -C. Moya www.cmoya.com
> I've noticed (for quite some time now) that .Net UIs are not as responsive > (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton [quoted text clipped - 6 lines] > Why do you think this is? Is it bad programming or is there something > else going on here? Jim Hubbard - 03 May 2006 01:14 GMT Perhaps that explains it.
One of the apps I noticed it most in was PlanPlus. I was using a notebook with a Celeron M processor and 1 GB RAM on XP Pro when I tested the trial version.
With no other applications running (and no processes running rampant in the background) whenever I clicked on a tab, you could almost watch the app redraw every tab and button when it switched tabs. Very ugly implementation. Looks unprofessional and slow.
Would I want to put my data into an app that looked ready to crash just changing tabs? I think not.
Franklin Covey prominently displays Agilix as a partner in the development of PlanPlus. Maybe they screwed this thing up. Maybe they used some very unprofessional controls. Who knows......
I just want to make sure my apps look more professional than that.
I REALLY wish the WPF was available to use. In the demos it looks professional, very fast and responsive. (Of course the PC it was running on may have been a CRAY supercomputer.....but, it looked good.)
> VB Classic made brilliant use of light-weight (not "real"... as in not > having hWnds) controls (The label, image, and shape controls) that were [quoted text clipped - 15 lines] >> Why do you think this is? Is it bad programming or is there something >> else going on here? Frans Bouma [C# MVP] - 03 May 2006 09:48 GMT > VB Classic made brilliant use of light-weight (not "real"... as in > not having hWnds) controls (The label, image, and shape controls) [quoted text clipped - 4 lines] > API (CreateWindowEx) as "Forms" and when an app has too many of them > it quickly degrades in performance. No, that's not the cause. Every win32/MFC app uses hWnd's under the hood and they're very fast. The main cause is that the asynchronous api of win32 is used in a synchronous way and that gives a lot of problems. Not only in delays, but also in events which occur in the wrong order etc.
FB
 Signature ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|