I have a conundrum. I have “inherited” a very badly designed and very complex system which I am modernizing and rebuilding (with my team) piece-by-piece. The problem is that the current system is depended on by 200+ users, and they are having major issues with performance due to the (lack of) design. The most problematic issue at the moment is that a significant amount of work is beng placed on the UI thread, which leads to the GUI hanging until the thread is cleared amd message pumping can continue. Much of this work actually does need to be on the GUI thread, as it is updating a large number of fields in a grid due to other calculation results on other threads.
The issue is this: I do not have the resource to dedicate to re-writing the threading model and underlying classes involved here, and the complexity of that work would introduce significant risk which is unacceptable to my client.
I wanted to know if anyone had any suggestions on how to make the UI more performant, without interfering too much with the currnet threading model.
My initial thought is that there might be some way to put a “buffer” in front of the actual invokes to the UI thread to make sure that the GUI does not get overloaded, or when it does to back off the dispatches to it.
Any suggestions would be greatly appreciated.
I know none of this is ideal, but we are where we are, and I really want to give my users a better experience prior to the year-long re-write’s completion!
Thanks!
Update #1
This is a winforms app…sorry this wasnt clear at the outset. New code is WPF, but these modules are winforms.
Update #2
I am thinking I may initially try changing most BeginInvoke calls to the UI thread to Invoke, introducing a serialization that will hopefully increase UI responsiveness.
Any (non-obvious) downsides here, that anyone can forsee?
I don’t know if it will work in your particular case, but I’ve been in a similar (though probably less stressful) situation in the past, and I came up with some code that let me marshal more-or-less arbitrary code from a background thread to the UI thread. This was written in the era of WinForms.
This may provide a lower-risk technique for you to throw some computation back on some background threads and marshal your UI updates more easily to the foreground without a full re-architecture of the threading model (or lack thereof).
Regarding performance of the UI, sometimes the best way to make it faster is to do less. The application I was working on when I created that linked code was parsing hundreds of megabytes of strings to manually munge some xml. Replacing immutable strings with stringbuilders took the operation from an OOM failure condition to completion within 5 minutes of wall-clock time. Then I noticed that, for every element it parsed, it updated the UI. I tweaked that code to update the ui every 50 elements or so, and that took it down to a fraction of a minute. Turning off all UI updates knocked the time down to a few seconds.
Have you considered not-updating the UI until the calculations are complete, perhaps just running a progress bar instead? One other possibility (off the top of my head, dunno how evil it is) would be to queue updates as lambdas in a dictionary that is keyed off of the control getting updated. That way you could replace redundant updates to values if a single control is updated multiple times, e.g. (This assumes that the app isn’t reading values directly from the UI to perform calculations, of course. Which it probably is. 🙁 )