C# background thread causes lag in UI

Question

I'm working on a realtime imaging system.

UI thread: grabs images from a camera at 14 fps via timer and does some processing/display. Every 2 seconds, 3 images (about 1mb on disk each) are selected by processing to be written to disk. These are put in a shared queue.

Second thread: dequeues images and writes to disk. Has been given 'Lowest' priority.

When the second thread is performing the writes, it takes a noticeable chunk of perf away from the UI thread and causes capture to drop below 14 fps. Not acceptable.

What can I do here? I don't mind if the writes take a longer time and queue up, there's plenty of RAM and a regular pause to allow the writes to catch up. The critical factor is for the UI thread to have enough juice to work at 14 fps.

Answer 1

To get a serious answer you should use some kind of profiler tool. If you search an stackoverflow or an google, you'll find plenty of them. Mostly you have to pay for them, but fortunately there also exists some trial versions which you can test to find the problem.

But my wild guess without any profiler is, that the I/O operation on the disk leads to your performance problems. So maybe you can work against it, if you try to use a SparseFile and / or MemoryMappedFiles (i know it is .Net 4, but cause it is just a wrapper against the Win32 Api you can maybe extract the class from there and use it in .Net 2).

Answer 2

realtime, windows and c# don't go well along together. if it's "not acceptable" for the framerate to ever drop below 14fps you could look for some realtime extension for windows, like RTX or INtime.

you could also try to write the files to disk in smaller chunks, add short Thread.Sleeps() inbetween the write operations to allow more task switches and make sure to flush the filestream after every write.

Answer 3

Maybe you should save files to different location after performing operations on it. It's possible that file is being lock while processed and UI thread waits for it to be free.

Answer 4

As other said: Hard realtime won't work here.

Try to find out if the devices share resources (bad example: Are on the same USB bus, both the disk and the camera). Check with a profiler if it is the CPU that throttles your capturing or the IO. Maybe it's just a fault of your code (leaking resources, wasting cycles). No one can tell, but you can (and should) check it.

Possible "solution", depending on your findings:

Use a queue (msmq for example) and just pile up images and never read from there (not even with reduced thread priority) until you reach your "pause". That would really require "ample amount of RAM" though.