|
Forgive my Java terminology. If you're in Python 2.7, the multiprocessing package is needed instead of using threads to speed up the jobs. Same design patterns, just more complicated implementations. The point I was trying to make was about user performance. When you block the event dispatch thread, the user has to wait for you to do all the editing i/o. If your change happens in the database cache immediately then forks, the gui can proceed and the user can continue to manipulate the library while a separate worker takes care of the slow io. If you're using the new global interpreter lock in python 3, then this doesn't give you any absolute speed advantage but the worker thread will release the GIL on I/O wait, returning it to the event dispatch thread, I believe. From the users perspective, it becomes far faster and allows them to start setting up the next edit while the software finishes writing out the previous edit. The current setup works decently well on my dev system (2ssd in raid0), but becomes painful when trying to edit a library on a thumb drive or 5400rpm laptop drive.
BTW, the GIL drive me crazy in the same way that the Java VM probably drives java developers crazy the first time they run out of heap space. Almost all my python experience is on Jython, which lacks the GIL, so I've only had to deal with it on one embedded project.
|