Running I/O bound tasks in parallel almost never offers any time advantage

If it's a single file, one a single disk, with a single controller, yes. But if you have multiple controllers, or reading from multiple files, I/O bound tasks can speed up when done in parallel. In fact, if you have just a one single core CPU, the only time threads will speed up things if you're I/O bound (disk and/or network).

And then there's the obvious two-way split: one thread doing I/O, while the other does the calculations. That means, your program can still make 'progress' while it's waiting for data. This may give you a speed up even if you have a single core, single CPU, single controller, single disk setup.

Now, I were the OP, and if I were to go the divide-and-conquer method, I'd try various method, and see which ones are faster on his particular setup:

1. Two threads/processes: one reading the file, the other checking the IPs.
2. Use threads/forks and have each thread/child test part of the file.
3. Have an outer thead/process reading chunks of data, have a bunch of other threads/processing each checking part of the IP addresses.

Obviously, the latter two allow for lots of tweaking by varying the number of threads/processes.

But first, I'd try something totally different. Instead of doing 3500 matches for each line, use a single regexp to extract all the IP addresses from the line (it doesn't have to be perfect, it's likely even /([0-9][0-9.]+[0-9])/ will do). The 3500 IP addresses, I would store in a hash. Then it's simple a matter of doing a hash lookup. This should dramatically reduce the number of matches performed. It may also fix a bug: if one of the 3500 ip addresses is "23.45.67.89", and the file contains "123.45.67.89", then it's reported as a match. This may be intended, but that I would find surprising.