MultiThread runs slower than single process MultiThread runs slower than single process multithreading multithreading

MultiThread runs slower than single process


The bottleneck is the disk.

You can access to the disk only with one thread per time, so using multiple threads doesn't help and instead the overtime needed for the thread switching will slow your global performances.

Using multithread is interesting only if you need to split your work waiting for long I/O operations on different sources (for example network and disk, or two different disks, or many network streams) or if you have a cpu intensive operation that can be splitted between different cores.

Remember that for a good multithreading program you need always to take in consideration:

  • switch context time between threads
  • long I/O operations can be done in parallel or not
  • intensive cpu time for computations is present or not
  • cpu computations can be splitted in subproblems or not
  • complexity to share data between threads (semaphores or synchronization)
  • difficult to read, write and manage a multithread code compared to a single thread application


There can be different factors:

  • Most important is avoiding disk access from multiple threads at the same time (but since you are on SSD, you might get away with that). On a normal harddisk however, switching from one file to another could cost you 10ms seek time (depending on how the data is cached).

  • 1000 threads is too much, try to use number of cores * 2. Too much time will be lost switching contexts only.

  • Try using a thread pool. Total times are between 110ms and 130ms, part of that will be from creating threads.

  • Do some more work in the test in general. Timing 110ms isn't always that accurate. Also depends on what other processes or threads are running at that time.

  • Try to switch the order of your tests to see if it makes a difference (caching could be an important factor)

    countLinesThread(num);countLinesOneProcess(num);

Also, depending on the system, currentTimeMillis() might have a resolution of 10 to 15ms. So it isn't very accurate to time short runs.

long start = System.currentTimeMillis();long end = System.currentTimeMillis();


The number of Threads used is very important. a single process trying to switch between 1000 threads(you have created a new thread per file) is probably the main reason for being slower.

try to use let's say 10 threads to read 1000 files, then you'll see the noticeable speed increase