If I run more then once the same solution, the execution time will be less and I understand that this happens because some of the data gets cached in the memory hierarchy (ram, or cpu registers etc).
So you should run several times (e.g. run five times exactly the same thing) the same "solution" and benchmark them all. The next question is what timing is the most relevant. You could choose the worst one (probably the first time), or you could consider an average of them, or ignore the worst and best runs and only care about the rest of them, etc...
In general, you cannot benchmark any software in exactly the same conditions because computer (and their operating systems) are not entirely deterministic, so you won't be able to reproduce exactly some running conditions. Hence, you need to make several benchmarks. Also "starting" or "cold-start" operation is not a typical running condition (but a special case), so you usually want to ignore it.
Remember that your hardware is non-deterministic: CPU cache behavior, CPU pipelining, superscalar processors with out-of-order execution, external interrupts -timers, networks, USB, disk, ...- and perhaps CPU frequency -limited when the chip is too hot- is changing without software control. Hence the kernel scheduler is behaving differently from one run to the next (because of preemptive scheduling, ...). Read also Operating Systems: three easy pieces for more about OSes. Some software layers (e.g. ASLR) could add more non-determinism.
In your case, I believe you want to consider the average time. In practice, it is very likely that some of the data is already "here" (e.g. in the page cache) when you would really use your program.
I dont think that measuring a "cold" state is realistic in your case. When you split a huge file, it is likely to have been generated (or downloaded, or obtained) a few seconds or minutes ago (why would you wait several hours before splitting it), so you really care more about a "warm" state, and in practice is it likely to be (partly) in your page cache.
Details are obviously computer, operating system, and file system specific. Don't expect your system to be deterministic and to give the same timings for several runs. So your benchmarks won't be exactly reproducible.
At last, your problem (splitting huge files of hundred of gigabytes each) is probably disk-IO-bound, not CPU bound, so the actual way of coding should not matter that much, at least if your buffers have suitable sizes (at least 128 kilobytes, and more likely a few megabytes; see setvbuf(3)...). If the files are not huge and could entirely fit in the page cache (e.g. if most files have a few gigabytes) things could be different.
BTW, on Linux, you might be interested by system calls like posix_fadvise(2) and/or readahead(2). When used properly, they could improve overall performance. And it seems that you are reinventing csplit(1) or split(1). Why are they not enough for your needs? Also, why do you need to optimize that much (remember that your developer's time costs more than the computer your program is running on).
Are you interested in splitting a thousand of files per day of a few gigabytes each, or splitting a dozen of files per day each of at least hundreds of gigabytes? These are two different problems! (I assume you have some ordinary desktop). And where do these files come from? How are they landing on your disk? What disk technology and file systems (SSD, rotating hard disks, remote filesystems) ?
PS. I am surprised by your question. Splitting a textual file (by e.g. thousands of lines) should not be an issue, and can be trivially coded in a satisfactory way (provided your buffers are large enough). I can't imagine a situation where such a splitting performance matters a lot (to the point of justifying several days of your work time). You need to explain your context, and motivate it much more. Of course byte size matters!
