ExecutorService performance issue

Question

I tried to get my hands dirty with Java Executor framework.So I created task which is nothing but string operations

withing for loop as below

for(int i = 0; i < noOfTimes; i++)
    str = str + 't';

Now my planning was to execute this task serially(one by one with for loop) and parallely(Using Executor framework and submitting all jobs at once and let it run) and compare their performance.So I executed below test cases.I have machine with 8GB RAM and Processor - Intel i7 which i think has 8 cores.

1.No of jobs(Task) - 30000 and each task would loop 1000(noOfTimes)

• a.Serially - 21.619
• b Executor framework - almost 13.8 sec

2.No of jobs(Task) - 30000 and each task would loop 5000 (noOfTimes)

• a.Serially - 433.34000000000003 secs
• b Executor framework - almost 325 sec

3.No of jobs(Task) - 5000 and each task would loop 15000 (noOfTimes)

• a.Serially(single core) - 661 sec
• b Executor framework(multicore) - 1154 sec

In case 1 & 2 as expected it clearly shows multithreaded approach is taking less time as compared to serial excecution But case 3 is almost reverse.So i have below questions

1. When should we go with serial execution or multithraeded approach(by taking advantage of multicore machine using Exceutor frameworks) for processing bulk amount of data(lets says i want to process 30000 employee records)

2. I observed in above test cases multithraeded approach is much faster in case single task processing is not time consuming(looping 1000 times) but once I increased processing time (loop 15000) for single task it is taking almost double time as compared to serial execution.

3. I wanted to check CPU usage in task manager mentioned at http://embarcaderos.net/2011/01/23/parallel-processing-and-multi-core-utilization-with-java/ but CPU was not utilizing all cores with 100% ?

Answer 1

First of all, you should try an other test.

String is immutable so doing str = str + "t" is actually not linear in time: adding only one character implies rebuilding the whole string everytime.

Plus because of the string pool in Java, I am not 100% percent sure String is the best object to test concurrency on.

Second, concurrency adds complexity to a program and the risk of unplanned behavior such as deadlocks, race conditions... A bad concurrent design can well be less efficient that an average serial design.

So if you are happy with your program and have decent performance, do not multithread. If you are unhappy with the performance, first try to find out why and improve your serial design. Only then you can add multithreading to it, but you really need to know what you are doing.