This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I'm using the PropertyGrid control version 6.0 and I would like to increase the performance on populating the grid when the "SelectedObject" property is set with a new value. I used RedGate performance profiler tool for analyzing where the CPU time is spent (see enclosed png file). I think that most of the time is spent for refactoring and for creating the editor template user control for each property of the selected object. Are you plan to increase the performances by implementing a sort of cache for refactoring or template editors ? |
|
|
Hello You are correct that most of the performance is going into creating and displaying the property editor controls. There are ways to improve this performance but this would take quite a lot of time to implement and could produce "breaking" changes in the visual appearance of the control - (Properties could each have a display mode and edit mode so that editors only exist when they are clicked). We have implemented these kinds of performance improvements before such as what we use in the DataGrid, so we may improve this in the future, but this isn't on our current roadmap. -Jason Fauchelle |
|
|
Hello Plese, could you give me an example project with DataGrid where the performance improvements are used ? Thank you very much. |
|
|
Hello The performance improvements are built into the DataGrid control itself. This includes virtualization, UI Element recycling, and display/edit modes for each cell to reduce the UI Element count. These are not external options, they are just built in to make the DataGrid perform well. WPF Elements includes an application called "Sample Explorer". Run this sample and navigate to the "DataGrid" category. Then find the "Large data set" demo. This will display a DataGrid with 70,000 cells - most likely a lot more properties than what you've loaded into the PropertyGrid. Despite this large number of cells, you'll see a noticeable difference in how fast the DataGrid loads up compared to when you switch large objects in the PropertyGrid. -Jason Fauchelle |
|
|
Hello, thank you for your feedback. I returned back to this point only today because I was out of office in last days. I think that a first optimization could be made by avoiding to recreate all editor template controls when selecting a different object but of the same type of previous selected object type. Do you think that should be possible to have this type of performance improvement on Property Grid ? Thanks. |
|
|
Hello Thanks for the suggestion. I will look into the possibility of this over the coming week and get back to you with how it goes. -Jason Fauchelle |
|
|
Hi Jason, any news to report ? thank you |
|
|
Hello Sorry I left this for quite late in the week. I've spent most of today looking into this performance improvement. What I have so far is working well and has significantly improved the performance, but there are still a few issues that I need to resolve before this can be shipped, and it will require quite a bit of testing too. I'll continue working on this early next week. -Jason Fauchelle |
|
|
Hello Unfortunately additional problems have cropped up during this performance experimentation. Each problem I attempt to solve causes other problems. I'm sorry to say we don't have time to continue down this path at present, but may look into this again in the future. -Jason Fauchelle |
|
|
Hi Jason, thank you for your update it's very sad you won't be able to fix this. I was wondering if maybe there is another shortcut to work around this. Since the object type we select is very complex but is the same type, would it be enough for you not to recreate all the propertyeditors for each object property and just update the datacontext of each propertyeditor ? we are facing a very bad performance issue difficult to justify to our customers thank you for your time |
|
|
Hello I too am sad for the bad performance here. What you have described is in fact what I had attempted to do. I kept running into issues with the existing nodes not correctly switching data context. Your idea certainly sounds easy enough, but due to the internal structure of the PropertyGrid, it is deceptively difficult to get it working. I still have all the code I was experimenting with, so would like to continue looking into this performance improvement when we have more time. -Jason Fauchelle |
|
|
Hi Jason, thank you for the update, when do you think you might have time to work on this ? Thanks |
|
|
Hello I've been spending some time investigating this issue to see if I can make a substantial improvements to performance. At present my improvements have not substantially improved performance at all so I have not committed them through - without a big win, I wouldn't want to run the risk of introducing regression issues (even though we have unit tests, it's always risky making very large scale changes). At this point, it's unlikely I can find a quick solution to improving the performance. I'm curious if perhaps you could reduce the size of the object you're trying to edit? For example, perhaps creating a simplified structure? I've also spoken with the team here and would be happy to extend your license to include the source code if you'd be interested in seeing if you could find a solution to your specific scenario? At this point, having spent a week investigating, I don't see an easy win unfortunately. -Jason Fauchelle |
|
|
Hi Jason, Objects are FrameworkElements, and this is the reason why performance are important because the number of properties cannot be reduced. What do you mean to extend the license including sources (in $) ? |
|
|
Hi, I can't comment on the performance particulars - but the source license was an offer to make the source available to you (at no charge) so you could also look at the performance characteristics of your situation better - and possibly work together on getting it working for your specific scenario. That's what Jason meant about the source license. Kind regards, John-Daniel Trask |
|
|
Hi John ok, let's give it a try, let me know how to proceed thanks |
|
|
Hi, I've upgraded your account in our store, so if you visit http://www.mindscapehq.com/store/myaccount You can now download the source code alongside. Kind regards, John-Daniel Trask |
|