pcmhacking.net

Hoping I can get some more help. I've been dipping my toes into the vs ide performance profiler. I've made some good gains however I'm now stuck and not sure if I've got it good enough or not. I'm focusing on the garbage collecting. I have created a logging config (I.e. max channels, fastest poll rate, log to file, log to screen) that stresses my app that I'm using for testing. I'm recording a GC pause of 40 to 60ms every 2-3 odd seconds. For a timing critical application that seems extremely excessive. Any one keen to offer some insights into the results screen shot?

It depends how fast you are logging data?

In my own applications, I do the following:
1) read data in on a background thread and save with a timestamp
2) update the UI on a background thread every 30ms (pause painting while updating all new Ui elements)
3) allow UI to refresh and run GC if required during this ‘idle’ time.

The data displayed should be accurate still since it’s time stamped. And it should look smooth since 30ms is about 33updates per second to screen yet allows adding hundreds of live data in that time.

Its coming in at 25ms intervals in dpid packets that I then am translating back via lookup to the individual pid objects.
I've got 3 threads running UI, J2534 and a file IO thread. I'm batching the file IO writes into 128Kbyte chunks. UI update is 10Hz.

Make sure the main UI thread is not actually running any large tasks or doing anything.

Use a background thread to post updates to the main UI thread (This keeps the UI running smoothly).

25ms DPID packets shouldn't be a problem at all. Time stamp the data as soon as it is received, that way the UI/data processed will not have any negative impact with the GC runs.

UI refresh rate can be increased, but it is a matter of ensuring you pause the paint event, update all UI elements, and then allow it to refresh all in 1 paint cycle.
If you don't do the above, it will refresh the screen for every single parameter that you update which will also cause the GC to run more frequently.

Thanks Tazzi. From first analysis to now I've got a 3x reduction in GC collection and have reduced SOH allocations significantly. My memory usage was creeping up over time but now I've got it flat no matter what I do with it which was nice to see. I'm moving some code around to which I think will help. I'll check out the on paint override, I think that's going to be a beautiful thing.