Yes, my analysis would only have applied to the single thread downloading. I think you are correct that there would be fairly consistent downloading with your multi-thread method, unless the parsing is very costly (but then you could just add more threads I imagine).
Regarding my actual process, the main thread creates 2 additional threads. Each thread gets half of the records. Each thread executes in a loop a HTTP call and a Xml Parse of each record.
So when I have for example 10 records each thread will do 5 http calls and 5 xml parsing.
For statistics i've been testing this for some time and at the moment the average performance rounds 4 seconds per record (each record makes http call, xml parsing and persistent store saving). And it still has some logging on sdcard wich will be turned off when app is ready. I'm testing the app on a bb curve 8520 wich as you already know has fewer processing power than the majority of newest bb devices.
Of course I have also verified that these processing has some issues regarding device performance and battery consumption but I think that 2 additional threads is a good balance between performance and overall device "health".
In my process i also noticed that the parsing takes a big longer than the http call.
I'm not sure which method to use as there are some things that I still don't understand like "thread pooling", "thread sleeping", "threadpool", device processor context switching etc
I will have to investigate and experiment more but the timeout situations on Http calls can be a important reason when deciding the right method to use.
For getting some conclusion to my initial question i can assume that the creation of new threads is costly to the performance.
................................................................................................ Tech On! PTNews more at On On On!