Closed ensisoft closed 7 years ago
We either need to reduce the work load on the GUI thread to an accetable level or offload the update to a background thread. However if another thread is involved then we need some kind of synchronization scheme between the threads.
It should be possible to refactor the update process so that the heavy lifting of doing the database updates is not done on the UI thread. Additionally vectoredio might be of interest here to support more efficient IO.
Current implementation offloads the database update to a background thread. The UI thread is given a list snapshot that the UI can use to reload/reopen the catalog views.
Currently the performance is much improved, so closing for now.
As future work related to this we could look into using vectored IO in the database update task to see if it'd run faster.
When the headers are updated and the engine is building the local database of the group the content's are also displayed on the UI. This means that the access to the data needs to be synchronized so that both tasks have a consistent view of the data and don't corrupt anything. This was initially resolved by offloading the database building (writing stages) to the GUI thread. This works fine on Linux but the performance on Windows is horrible. The application is often in "not responding" state.