I suppose you were testing on a desktop machine; pushing the boundaries of my knowledge, is it possible that I get a very different result because I am mainly testing on servers (HP-UX), where there is a possibility that the heavy use of I/O is slowing down the process ?

Looking at the second profiler image, it isn't IO that is constraining your process, but rather memory allocation. Which is rather difficult to understand given that processing 100x 200,000 line files only requires 36MB & 147 seconds on my machine.

The only way I can see that happening is if the server in question is so overloaded memory wise that it is permanently swapping, so that every split to an array and push to an array requires the machine to wait for substantial IO. And given that the profiling shows that the actual file IO done by your program isn't taking long at all, then the server must be using a ludicrously heavily over-subscribed separate swap partition.

Under those circumstances, there is nothing you can do to your script that will improve its performance. The only way will be to get the processing moved to a server with more (SOME!) free resource.

Were I you, I would run the program on my workstation (or development server) and profile it there, and then take the two profiles to someone in authority and show them how badly the server resources are being managed. Demonstrate not only that your process is being dramatically choked by being run on a server that is totally inadequately provisioned for the tasks being given it; but that all the other processes running on that same server, will be being similarly choked and hampered by the same problems.

Just for completeness, here is my test setup:

And a run on the 100 files with limit set to 20:

C:\test>junk47 -N=100 -L=20
147.615
[download]