As others have said ... “it entirely depends upon what you are doing.”

The task that you are performing is I/O-bound.   The speed at which the procedure will complete, is ruled mostly by the efficiency with which it is able to perform disk I/O.   No matter how bad-and-hairy “a log file record” might be, you can be fairly certain that any decent CPU on this planet will be able to dispose of it in a handful of microseconds.   But even the fastest disk-drives are still ruled by milliseconds.   Therefore, if you subdivide such a procedure into n parallel tasks, each of which are given the same job to do, then you can safely predict that n-1 of them will be spinning their wheels.   There is a price to be paid for those threads, and you’re paying it.

Now, in contrast to this scenario, let’s briefly contemplate one that might be a truly useful application of threads.   In this scenario, once a disk record has been read in, it might be a command for the computer to perform some unit-of-work that consists of a varying (and unpredictable) amount of CPU-plus-I/O activity.   Now it might well be productive to assign one thread to the task of “disk I/O,” and a pool of n threads to the task of doing the work.   The number of threads in the pool (n) is rigidly controlled (and adjustable).   The number of threads devoted to disk I/O is limited to 1 because, well, there’s only 1 device to be waited on.