As you may have heard before, at DevExpress we allocate some resources in each release timeframe to find and eliminate performance issues in existing controls and components. After v18.1 came out, we started focusing on the Ribbon Control and the results of this work are included in v18.1.5.
A starting point for performance improvements was provided by the XAF team. They described some scenarios to us where real-world applications that use the XAF Office Module take quite a while to load. There was a suspicion that the behavior was due to a heavily populated Ribbon. Armed with a profiling tool, we started digging into sample applications to investigate in detail, and we identified a number of weak spots where certain calculations were performed more than once, objects created and then dropped, or similar.
None of the issues we found were very serious individually, but we reckoned that improvements would still amount to reasonable performance gains cumulatively. Since the Ribbon is a core component of many applications, we made the effort and managed to improve low-level performance by 13%. To measure the gains, we started the RibbonSimplePad demo 50 times, and its average initialization time dropped from 2080 to 1810 milliseconds (that’s without NGen precompilation).
After the initial success on the Ribbon level we moved on to the mechanisms implemented in many of our Office controls, which generate Ribbon configurations. These implementations are part of the Rich Edit, Scheduler, Spreadsheet, PDF and Dashboard suites, and also the XAF Office Module. We made several improvements in this area, including these:
- Icons retrieved from the Image gallery are cached
- Initialization processes are improved for the Color and Font editors, using asynchronous loading and other techniques
- SvgParser internals have been fine-tuned to avoid reflection
- Ribbon item creation algorithms have been reworked for control commands like CreateAppointment, OpenDocument, etc
The benefits for real-world applications are impressive! The XAF Office Module represents much of what a “real-world” application does, and the time it takes to initialize and show itself has been reduced by up to 70%:
In addition to the XAF Office Module tests, we also conducted a series of artificial test where we measured the time it takes a form with an Office control and its associated Ribbon to show up. We used benchmarking applications precompiled with NGen, and we measured both design-time and runtime generated Ribbons for the Dashboard suite (the other control suites don’t have a standard generation mechanism working at runtime). Here are the results in milliseconds:
| v18.1.4 | v18.1.5 | Gain | |
|---|---|---|---|
| Dashboard (Ribbon generated at runtime) | 3333 | 652 | 80% |
| Dashboard (Ribbon generated at design-time) | 825 | 560 | 32% |
| Spreadsheet(Ribbon generated at design-time) | 1400 | 980 | 30% |
| Scheduler (Ribbon generated at design-time) | 526 | 467 | 11% |
If you would like to reproduce the results, you can use our benchmark project on GitHub as a starting point.
As always, we are interested in your thoughts! It is our expectation that most WinForms applications will benefit from performance improvements like those we achieved here. Please let us know your findings!