12-15-2011 06:12 PM
I have a situation where i need to do some processing using 2 adittional threads
i have 50 records to iterate and for each iteration I need to do 2 types of processing(http calls and xml parsing).
should I divide the records and assign 25 records for each thread?
or could I have the first thread iterating the 50 records and create a new thread for each record?
how performant is the creation of new threads?
what's your opinion?
12-15-2011 06:57 PM
I would create a processing Thread that does the required processing, and then alter the number of these you start. Just have a queue of things to process and synchronise this when each Thread removes an entry.
I have found that the newer devices can run multiple Threads quite easily, on older devices, users will notice a lot of background activity, so you might want to have fewer Threads on an older device.
12-16-2011 06:07 AM
thks for the reply peter.
however I still have this question:
how performant is the creation of new threads?
it's prefered to create a new thread to process 25 records or create 25 threads to process 1 record each?
12-16-2011 06:28 AM
The issue here is not the number of Threads, but the processing that each Thread is doing. Same as on a PC. For example, there is no point trying to run two video editing processes at the same time on a single CPU PC. The CPU is the bottleneck.
Typically on a BB, the network is the bottleneck. Running multiple Threads, all trying to access the network does not help. The second bottleneck is the processor, so parsing two large bits of XML at the same time will not help on the BB - it only has a single processor.
In this case I would expect that you would get best performance with 2 or 3 Threads. So if you put your requests in a queue, and create a Thread that processes from the queue, then you can start one Thread and have one processing Thread, or start two and have two processing from the queue. Or start 3 and have 3 processing. That way you don't need to decide how many now, you write your processing and try it. And you might find that in a WiFi area with one of the new processes you get better performance with 4 Threads, but in a non wifi area with an older device, you are better with 2.
Is this clear?
12-16-2011 07:29 AM
I recommend using threads only for the purpose of preventing bottle-necking. Threads should be used so independent tasks do not block eachother. Since I believe the iteration in your application is occurring as a batch process, I think the fastest way to process your data is:
-Use one thread is for the HTTP processing
-Use one thread is for the XML parsing
Using threads this way ensures you aren't blocking costly processes that use different areas of the hardware (HTTP-get predominantly blocks processing as it waits for the radio and XML parsing predominantly blocks processing as the CPU processes). Put all the items in a queue for download with the HTTP thread, then as each item is downloaded, pass it over to a queue in your XML thread. When your XML thread is done with the item, it can pass the information back to your event thread for an update to the UI or whatever needs to be done next.
To answer your other question, thread creation is typically considered an expensive task. If you could create 25 threads I think would result in poorer performance.There's only so much processing power that you're going to get from the system and adding needless threads is probably going to make performance worse. Besides that, there is a limit to the number of threads that can be running at the same time (on BB, I believe it is 16 per application, and 64 for the whole system). So the more threads you occupy the fewer applications the user can have open while they use your application.
Since I have gone this far in my response, I might as well split some more hairs. If you knew something about the data being downloaded like which items should be downloaded first to give the best user experience and which items could be downloaded with minimal priority, you may want to create threads of different priority. If your application is demands frequent, short use of threads (ie. not a batch process), you can use something called thread pooling. But I think you will probably just want to use the two-thread message I mentioned above.
12-16-2011 07:37 AM
12-16-2011 07:50 AM
I should add, I don't do a lot work with HTTP connections and when I have, it's been to interact with one server. One problem I foresee with using just one thread for HTTP-get as I suggested, is if there was one URL that was invalid and it was going to timeout, all of the other http-get requests may be blocked.
12-16-2011 08:51 AM
Good point on the 'timeout' of the http processing.
Personally I would not split the processing up to http and parsing anyway. Doing so means that you need to manage two queues, one for the download and one for the parsing. I quite like being able to delegate one complete job to one Thread, rather than trying to use a production line type approach. But that is just me.
As I understand it, the Thread limits given above (16/64) were correct at one time, but I am reasonably sure that the limits are significantly higher now. Also while I do appreciate that Thread creation and the associated context switching is considered "expensive", I don't think this or the Thread limit should be used as the key design criteria. The important thing to consider is whether using more Threads helps. In this case, to my mind anyway, it clearly does not., in fact it will hurt.
And one final thing. I have had some very weird results attempting to use the Thread priority mechanisms. In one application I download a number of images that I use to populate a ListField. Running the download Threads at low priority actually significantly slowed down the arrival of the images and seemed to cause these to lock out the Ui while updating it for longer. Purely anecdotal I know, but the only Threads I now run at low priority are things that have no user interaction - for example the resysncing of data.
12-16-2011 04:56 PM
Thanks for the feedback, Peter and Simon! It's very useful.
If XML parsing took 40-100ms for each iteration, after 50 iterations you would have finished downloading all the items 2-5 seconds sooner by seperating the HTTP and XML parsing into different threads (a bit of a crude calculation on my part). Not a bad savings, but still not might be enough incentive to want to create an extra thread or queue for XML parsing which would be rather labourous.
12-16-2011 07:01 PM
@superdirt. I know that this is getting off topic and this is purely a theoretical discussion. However I wonder if your analysis is comparing like with like.
In your scenario (call this A) I think you you assume two threads, one doing XML and the other doing download, and you assume that the XML parsing can take place in one Thread while the download is taking place in the other.
The time saving you have calculated assumes that there is only one download and parsing Thread running at once.
However if you compare A with two Threads that each process both the download and the XML parse, which is what Simon and I were suggesting (call this B), is there a difference?
Let us assume that XML processing and download can overlap. Then I think in both cases, A and B, the expected time for 50 iterations is
50 * max(download time, parse time) + min(download time, parse time)
But I wonder if this is best case for A, and might be the worst case for the situation B. What do I mean worst case? I wonder if B can go faster than that because in B, there is a chance that the "bottle neck" can also overlap. For example, I would have thought that there was a good chance that two threads doing a download at the same time would get the two downloads completed faster than one Thread doing two downloads. Now if the download was a more significant part of the time than the parsing (which over a mobile network appears likely), then being able to overlap that will give you a significant advantage when compared to having just one Thread doing the downloading.
Anyway, it is an interesting thought experiment.