When a user loads a project file into my application it can take a long time – several 10’s of seconds. I understand the concept of using a background thread to process something that blocks the UI. However, in this case, there is nothing for the user to do – they are waiting for the project file to load – other than watch the progress messages.
I am looking at parceling out the processing of different project elements among different threads. However I am not at all clear if this would really make a worthwhile difference. Some project elements do consume a lot more time in being created but generally the complex ones are few in number and the simple ones are large in number. Processing involves creating some drawing code so that the element can be displayed on a canvas.
I understand the concept of time slicing between threads but as far as I can see the total time taken is not changed and there could be some overhead in using threads.
I also understand that for multi core processors then some true concurrency could take place if the threads are distributed between processors (sorry I do not know enough about threading to know if this the correct description). I don’t know if this is easy to arrange. Clearly it would not help a user with a single core processor.
Changing the code to try it out is not a trivial task so I would take your views on whether this is worth trying.
Thanks.
As a rule, multithreading a loading process will not save time, because often the process requires things to be done in a certain order, later aspects cannot be processed until previous ones have done. It very much depends on your actual loading process. It may also be the case that the loading is taking time because of core .net processes. In either of these cases, threading will not make a significant difference.
What you have to consider is whether there are significant parts of the task that are obviously unconnected to each other. Only in this case will it possibly be faster, but you will only then take the speed of the faster process out of the time. And by adding in threading to any significant degree there is a real chance that you will slow the processing down, becasue there is a cost to this code.
You would possibly do better to consider if you can lazy load some aspects of the project – anything that may not be always required at the start might be a possibility for deferring. Or even, depending on the processing structure, whether you can return control to the user before completing the load, which continues in the background. This does not make it any quicker, but does give the impression of being quicker.