I presently possess a scenario in which a 1000 actions could occur within seconds and I have to store each one of these actions inside a database.
Things I presently do is have a idle timer, once this timer reaches a pre-defined time, I go ahead and take cached actions (actions since last commit - which is simply a simple list) and commit individuals actions towards the database.
The UI must be responsive as you possibly can (duh?).
Apart from pushing the database logging to some seperate thread, are there more suggestions in relation to performance that anybody can assist me with?
Use third party logging frameworks like NLog that have asynchronous logging wrapper.
Log those things towards the tail of the log file because the actions occur. It has two benefits. It's real fast and thus your UI continues to be responsive also it implies that when the application crashes those things aren't lost.
Then possess a background thread that can take those things within the file and updates the database. After the application crashes you are able to restart and also the background thread simply updates using the actions which were securely saved previously. You can actually have a separate application/process/home windows service that does the backdrop update and also have the UI application only perform log writing.
Should you really must avoid another thread then you should carry out the database udpates in really small batches, so that they are as quick as you possibly can, as well as in idle time processing. But this method is definitely likely to be inferior since the database operation becomes synchronous together with your UI. So that your UI dangles for that duration. Any database problem like a timeout because of connectivity problems then kills the UI.