Performance concern while opening a dialog repetitively in wpf
I have a launch dialog button which creates a view model of a window and bind it to the the window(it is having UI virutalization enabled). It takes only 1 second to launch the dialog at first click. But if I open the same dialog very frequently or back to back, it starts taking more time in populating the grid data source for next iteration. if I give some pause, then again open window, then it takes only approx 1 or 2 seconds.
for first time populating the item source it take only 1 second:
next time populating the item source it takes 2 second
next time populating the item source it takes 3 second
next time populating the item source it takes 6 second
next time populating the item source it takes 8 second
However, if I call GC.Collect() which is not recommended, then populating grid data source always takes approx 1 second. but calling of
Gc.Collect()
Gc.WaitForPendingFinalizer()
Gc.Collect()
cost me some time for every iteration.
I know calling GC.Collect is not a good option. Can anybody suggest how can I boost my application performance.
I am more concerned about the user machine as my machine is with very good configuration whereas user machine may not so fast.
It is difficult to pinpoint the exact issue without looking at the code. However, usually this can happen due to a few reasons.
It loads more data (may be double?) evertime. You have indicated it loads only 200 records everytime. But make sure your logic is correct and it clears previous data before you re-publish.
Make sure you unsubscribe from any event subscriptions. Sometimes there can be hiden events triggering for previous grid instances. You can easily check that by putting a break on an even handle and checking if it trigger more than once.
Look at every Disposable instances you are creating and check if you dispose them appropriately. Probably you are not disposing disposable instance and that may be the reason that GC.Collect help.
I am not quite sure about virtualization involvement here. Perform the same test without virtualization to make sure that's not the reason.