WPF Performance
-
No, not at all. We have converted a rather large application from WinForms to WPF and were quite satisfied. No flickering or other artifacts while updating the views and the logic behind them was the same. What exactly is not performing so well?
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan KenobiInitial display of the chart, or clicking a checkbox to show/hide a series takes almost a second (maybe a little more) to update the chart, regardless of the number of data points being displayed. The WinForms app exhibits an instantaneous change.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Here[^] (I hope) some insight: see the notes below the question.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]That's got some pretty funny comments, the most humorous of which is the casual use of the word "trivial" when talking about WPF. Yeah - it's trivial if you don't need to color outside the lines. Reputationator has some requirements that prevent the use of Xaml in some instances. In both the winforms app and the WPF app, I build the chart objects in the CS files, mostly because it's easier to do it that way, but there are other reasons. BTW, I have a DX10-compatible video card (nVidia 8800GTX), so I don't think that's the problem.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
That entry appeared after the blog post saying that it wasn't a real word.
Do you believe all the blog posts you read? If so, I've seen a few from people that talk about the reptillian aliens that are controlling our planet from secret underground lairs. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Initial display of the chart, or clicking a checkbox to show/hide a series takes almost a second (maybe a little more) to update the chart, regardless of the number of data points being displayed. The WinForms app exhibits an instantaneous change.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997That is strange. Our program was a webservice client and the WinForms version was based on an expanded MVP pattern. We ported the little MVP framework to WPF, so that we could continue to use the logic of the WinForms version and only had to redo the views themelves. Naturally, the data access over the webservice did not get any faster or slower, but we have had no noticable further delay. The views are WPF user controls and data is usually supplied by the presenter, so little to no data binding is used. Perhaps this is what slows you down. Edit: Fixed some typos
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobimodified on Thursday, August 25, 2011 9:05 AM
-
I'm finishing up on a WPF version of Reputationator, and have observed that the WPF app UI is markedly less performant than the WinForms version. Has anyone else done something similar (create a winforms and wpf version of the same app), and then observed similar results? I have to admit that I was somewhat shocked.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997If your main problem is with the graphs (As the other posts on this thread suggest), then I'm not surprised. The data visualization libraries are a little slower than the rest of WPF, since they treat every point/line on the graph as a control with full event handling and such. If you're using the WPFToolkit in 3.51 (I'm not sure how much they improved it for 4.0), there are also a few quirks that really kill performance. I had to hack my way around them. For one, there are a lot of built-in animations that slow everything down by default... You can bypass some of those by doing a TransitionDuration="0" on most series. Also, take a close look at how you're updating your data objects... Remember that every update to a bound object gets pushed through to the GUI, so try to minimize the number and do them in chunks (For instance, do a Clear instead of wiping out points one by one). But all in all, yeah, you'll see a performance loss in moving to WPF... You spend a little CPU time, and you get a better-looking app with more functionality and maintainability than doing all of that stuff manually in WinForms.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Do you believe all the blog posts you read? If so, I've seen a few from people that talk about the reptillian aliens that are controlling our planet from secret underground lairs. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997:-D No I don't, but I do know that "performant" isn't a real word!
-
No, not at all. We have converted a rather large application from WinForms to WPF and were quite satisfied. No flickering or other artifacts while updating the views and the logic behind them was the same. What exactly is not performing so well?
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi -
Nishant Sivakumar wrote:
WPF data-binding works faster than when you manually add remove items,
That is what I am surprised at. How can reflection and binding can actually lead to better performance then directly adding items? Something is not adding up here. WPF performance issues are mostly due to rendering, so I am more surprised that data-binding or not will improve the performance. Win32 (hence Winforms) rendering is actually faster. Do you know what WPF is doing to optimize the data binding which causes improvement in performance? I doubt they can bypass reflection.
Rama Krishna Vavilala wrote:
That is what I am surprised at. How can reflection and binding can actually lead to better performance then directly adding items? Something is not adding up here. WPF performance issues are mostly due to rendering, so I am more surprised that data-binding or not will improve the performance. Win32 (hence Winforms) rendering is actually faster. Do you know what WPF is doing to optimize the data binding which causes improvement in performance? I doubt they can bypass reflection.
Ok I am not explaining myself well I think. Imagine this scenario, you have a combobox where you want to show country names and another combobox where you want to show state names corresponding to the selected country. (1) Data-binding scenario: Initially, this is slow. Reflection is involved when the data is bound. This is a one-time cost. Now as you change the selection in the country combobox, the states combobox is bound to the selected-item's states property (assume each country object has a states collection). This update automatically happens through property change notifications (assuming you've correctly bound to the selecteditem). (2) Direct manipulation scenario: Initially, this is faster since there's no reflection involved. But consider selection changes. The country combo's selection changed event is handled. Now the user code has to get the new selected item, get the states collection and then manually clear/re-populate the states combobox. In my view (2) is slower in the long run. This gets worse if you have a 3rd bound control, say an image which has to show the country's flag. Now with data-binding this is merely a matter of property change event handling and binding to selected item. With direct manipulation there's more work involved. Not to mention that user written code may have further inefficiencies that may not be obvious. Again I suspect my explanations are probably not very clear so maybe I am not making my point here.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Yes - everything involving collections is being databound. However, When I was working on a WPF project back in 2009, using binding or not using binding provided no difefrence in the UI performance (and if anything, NOT using databinding should be faster since you're probably not using reflection when performing the task manually.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997What controls do you you see being slow? List controls?
Regards, Nish
My technology blog: voidnish.wordpress.com
-
If your main problem is with the graphs (As the other posts on this thread suggest), then I'm not surprised. The data visualization libraries are a little slower than the rest of WPF, since they treat every point/line on the graph as a control with full event handling and such. If you're using the WPFToolkit in 3.51 (I'm not sure how much they improved it for 4.0), there are also a few quirks that really kill performance. I had to hack my way around them. For one, there are a lot of built-in animations that slow everything down by default... You can bypass some of those by doing a TransitionDuration="0" on most series. Also, take a close look at how you're updating your data objects... Remember that every update to a bound object gets pushed through to the GUI, so try to minimize the number and do them in chunks (For instance, do a Clear instead of wiping out points one by one). But all in all, yeah, you'll see a performance loss in moving to WPF... You spend a little CPU time, and you get a better-looking app with more functionality and maintainability than doing all of that stuff manually in WinForms.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)The chart is completely cleared of old data every time an update occurs. I'll change the delay thing you specified, but the actual visual delay is ocurring befor the chart is even rendered.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
I'm finishing up on a WPF version of Reputationator, and have observed that the WPF app UI is markedly less performant than the WinForms version. Has anyone else done something similar (create a winforms and wpf version of the same app), and then observed similar results? I have to admit that I was somewhat shocked.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997A lot of it depends on the design. If you drink the WPF Kool-Aid and have more than a handful of objects that render and notify you will suck it royally. I ripped out all of the notification in one of my apps and went to old fashioned updating and it sped up quite a bit. In WPF's defense however, I had about 80,000 updateable objects each that could notify when it was changed.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Rama Krishna Vavilala wrote:
That is what I am surprised at. How can reflection and binding can actually lead to better performance then directly adding items? Something is not adding up here. WPF performance issues are mostly due to rendering, so I am more surprised that data-binding or not will improve the performance. Win32 (hence Winforms) rendering is actually faster. Do you know what WPF is doing to optimize the data binding which causes improvement in performance? I doubt they can bypass reflection.
Ok I am not explaining myself well I think. Imagine this scenario, you have a combobox where you want to show country names and another combobox where you want to show state names corresponding to the selected country. (1) Data-binding scenario: Initially, this is slow. Reflection is involved when the data is bound. This is a one-time cost. Now as you change the selection in the country combobox, the states combobox is bound to the selected-item's states property (assume each country object has a states collection). This update automatically happens through property change notifications (assuming you've correctly bound to the selecteditem). (2) Direct manipulation scenario: Initially, this is faster since there's no reflection involved. But consider selection changes. The country combo's selection changed event is handled. Now the user code has to get the new selected item, get the states collection and then manually clear/re-populate the states combobox. In my view (2) is slower in the long run. This gets worse if you have a 3rd bound control, say an image which has to show the country's flag. Now with data-binding this is merely a matter of property change event handling and binding to selected item. With direct manipulation there's more work involved. Not to mention that user written code may have further inefficiencies that may not be obvious. Again I suspect my explanations are probably not very clear so maybe I am not making my point here.
Regards, Nish
My technology blog: voidnish.wordpress.com
Reputationator isn't NEARLY that complicated. The two comboboxes on the form are populated only once, the two ListViews are ppopulated only once. Only one control (the CheckListBox) is a two-way control (and it's also only populated once). The delay happens whenever I change any criteria for the chart. When the chart criteria change, the existing series are removed, and a new set are added, and the only chart stuff that lives in the XAML are the various data point control templates, so that means that 99% of the chart building happens in the code as opposed to the XAML. The Winforms version essentially does it the same way. I hope to be posting an update to Part 4 of the series with the finished code sometime this weekend. You can look at it then if you want to. It's certainly not a show stopper, but the difference in respovieness is noticable (and I'm running a quad-core 16-gb machine at home).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
CDP1802 wrote:
converted a rather large application from WinForms to WPF
Why would on want to do that ?
Now that's a long story. First it was a web application, but we found the UI to be lacking and inflexible. That's why it became a WinForms application connecting to the server over a webservice. Actually it's two separate clients, one for administration and one for the users. Some modules are shared by both, including libraries with presenters and views. Showing the views in a consistent design was not easy to do when they were imported from a library and at least the user client had to look good. That's why we moved on to WPF and did not regret it. To be honest, by now the user client has moved on to XNA, we have written our own UI for XNA, but it still runs on the same old logic and MVP. Only the views have been replaced, using XAML for our own UI. The administration client will remain with WPF, no need to port that to anything else as well.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi -
Reputationator isn't NEARLY that complicated. The two comboboxes on the form are populated only once, the two ListViews are ppopulated only once. Only one control (the CheckListBox) is a two-way control (and it's also only populated once). The delay happens whenever I change any criteria for the chart. When the chart criteria change, the existing series are removed, and a new set are added, and the only chart stuff that lives in the XAML are the various data point control templates, so that means that 99% of the chart building happens in the code as opposed to the XAML. The Winforms version essentially does it the same way. I hope to be posting an update to Part 4 of the series with the finished code sometime this weekend. You can look at it then if you want to. It's certainly not a show stopper, but the difference in respovieness is noticable (and I'm running a quad-core 16-gb machine at home).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Ok, so it's the chart that's slower. I don't have any experience with that. But then this is rather disappointing that a framework meant to be used in graphics intensive sitations is slower than its winforms equivalent. :)
Regards, Nish
My technology blog: voidnish.wordpress.com
-
A lot of it depends on the design. If you drink the WPF Kool-Aid and have more than a handful of objects that render and notify you will suck it royally. I ripped out all of the notification in one of my apps and went to old fashioned updating and it sped up quite a bit. In WPF's defense however, I had about 80,000 updateable objects each that could notify when it was changed.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
The chart re-renders when the user selects/deselects a series, chooses a different chart, or chooses a different time period to show the data for (none of the rest of the app is affected). Even if you're taking about a handful of data points, the delay is obvious.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
The chart is completely cleared of old data every time an update occurs. I'll change the delay thing you specified, but the actual visual delay is ocurring befor the chart is even rendered.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Well, that might be a problem... The charts are great at incremental updates, but a full redraw is a full redraw, and that's going to take time to re-generate all of those tiny little FrameworkElements.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
What controls do you you see being slow? List controls?
Regards, Nish
My technology blog: voidnish.wordpress.com
The chart itself.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Well, that might be a problem... The charts are great at incremental updates, but a full redraw is a full redraw, and that's going to take time to re-generate all of those tiny little FrameworkElements.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)BUT, the winform app is considerably faster (almost instantaneous).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Now that's a long story. First it was a web application, but we found the UI to be lacking and inflexible. That's why it became a WinForms application connecting to the server over a webservice. Actually it's two separate clients, one for administration and one for the users. Some modules are shared by both, including libraries with presenters and views. Showing the views in a consistent design was not easy to do when they were imported from a library and at least the user client had to look good. That's why we moved on to WPF and did not regret it. To be honest, by now the user client has moved on to XNA, we have written our own UI for XNA, but it still runs on the same old logic and MVP. Only the views have been replaced, using XAML for our own UI. The administration client will remain with WPF, no need to port that to anything else as well.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan KenobiIsn't XNA A game framework?
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Isn't XNA A game framework?
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Once you have a UI that's irrelevant, or not? In combination with a 3D engine you can do really neat stuff. But you are right. It was a game that started out as something like a browser game and then slowly became something entirely different. For me it was a hobby, for another promising young developer it was a start to learn a lot of things and we have quite a few modules which are not only good for writing a game. And it's very well possible that we may soon put that code to some good use like earning some real money.
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi