Periodically release the locks on the database as the sync with the
server is being performed. This allows the UI to communicate with its
database and update the UI in real time.
Taken this oppurtunity to refactor some common code improve
maintainance.
Previously the user was able to set any number to limitThreads UI
component but internally that was reduced to be a maximum of 50 which is
deceiving to the user. Set this is set as a boundary in the UI.
This also fixes a bug that the user could set the number of threads to
zero which follows from GIGO; but let the UI assist by placing a min
number of threads to 1.
json.dumps is a processing intensive operation. This is being called
every time data is received from the server (most noticeably during
library updates) for debug logging. If the user has debug logging
disabled (the default option) then the user is still paying for
processing which is discarded.
The fix is to add a level of indirection where the dumps function is
only called if a string representation of the json is requested; ie.
when the debug string is evaluated.
json.dumps is a processing intensive operation. This is being called
every time data is received from the server (most noticeably during
library updates) for debug logging. If the user has debug logging
disabled (the default option) then the user is still paying for
processing which is discarded.
The fix is to add a level of indirection where the dumps function is
only called if a string representation of the json is requested; ie.
when the debug string is evaluated.
implementation dependant although with CPython elements are
unintentionally skipped during iteration.
Basic CPython example:
>>> A = [1,2,3,4,5,6]
>>> for a in A:
... A.remove(a)
>>> A
[2, 4, 6]
