Will using threads save time?

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 o开发者_开发知识库f 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.

Adding multithreading does not inherently make things faster. If multiple threads end up competing for shared resources, the program could very well end up running (much) slower.

You say you have lots of objects, some small, some large. Multithreading could help the user have a sense that things are going faster, then. Also, like you say, a multicore processor would likely see benefit (as long as your processor affinities are the default, it should work OK). Most people probably buy multicore computers today, and in the future, you should expect all computers to be multicore.

If the time consuming task could be separated into smaller independent tasks then running those tasks on multiple threads would be faster as you would paralellize the execution. If you are using .NET 4.0 I would recommend you looking at the TPL library which is built in.

The biggest problem with threads is to be able to partition your algorithm in smaller pieces that could be executed in parallel and independently. This way you will have a net gain in performance. But unfortunately not all algorithms could be parallelized. In this case simply run the entire operation on a background thread to avoid freezing the main UI. You will not gain any speed by doing this nor your application will load any faster, but at least the user will not get a Not Responding in his window title bar and you will be able to show some progress indicator.

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.

Why not try it? Take your largest, heaviest file load, thread it off and see what happens. There are scenarios where threading off loads can be much faster, eg. the @TMN case where a large number of smallish files need to be loaded over a network - setting up a connection over a high-latency network to transfer a small file can take longer than transferring the file data. Even a single-core box would show large speedup in such a case.

Rgds, Martin