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).
Quindi dovresti eseguire più volte (ad es. eseguire cinque volte esattamente la stessa cosa) la stessa "soluzione" e confrontarle tutte. La prossima domanda è quale tempistica è la più rilevante. Potresti scegliere il peggiore (probabilmente la prima volta), o potresti considerarne una media, oppure ignorare le peggiori e migliori esecuzioni e preoccuparti solo del resto, ecc ...
In generale, non puoi confrontare alcun software esattamente nelle stesse condizioni perché il computer (ei suoi sistemi operativi) non sono completamente deterministici, quindi non sarai in grado di riprodurre esattamente alcune condizioni di funzionamento. Quindi, è necessario fare diversi benchmark. Anche l'operazione di "avvio" o "avvio a freddo" non è una tipica condizione di esecuzione (ma un caso particolare), quindi di solito si vuole ignorarla.
Ricorda che il tuo hardware è non -deterministico: cache della CPU comportamento, pipelining della CPU , superscalar processori con esecuzione out-of-order , esterno interruzioni - timer, reti, USB, disco, ...- e forse Frequenza della CPU -limitata quando il chip è troppo caldo- sta cambiando senza controllo software. Quindi il scheduler del kernel si comporta in modo diverso da una corsa all'altra (a causa della pianificazione preventiva, .. .). Leggi anche Sistemi operativi: tre parti facili per ulteriori informazioni sui sistemi operativi. Alcuni livelli software (ad es. ASLR ) potrebbero aggiungere più non determinismo.
Nel tuo caso, credo che tu voglia considerare il tempo medio. In pratica, è molto probabile che alcuni dati siano già "qui" (ad esempio nella cache di pagina ) quando userebbe davvero il tuo programma.
Non penso che misurare uno stato "a freddo" sia realistico nel tuo caso. Quando dividi un file enorme, è probabile che sia stato generato (o scaricato, o ottenuto) pochi secondi o pochi minuti fa (perché dovresti aspettare diverse ore prima di dividerlo), quindi ti preoccupi di più di uno stato "caldo" e in pratica è probabile che sia (parzialmente) nella cache della pagina.
I dettagli sono ovviamente computer, sistema operativo e file system specifici. Non aspettarti che il tuo sistema sia deterministico e dia gli stessi tempi per diverse esecuzioni. Quindi i tuoi benchmark non saranno esattamente riproducibili.
Finalmente, il tuo problema (dividere file enormi di centinaia di gigabyte ciascuno) è probabilmente legato all'IO-disco, non alla CPU, quindi il modo effettivo di codifica non dovrebbe avere importanza, almeno se i buffer hanno dimensioni adeguate (almeno 128 kilobyte e più probabilmente pochi megabyte; vedere setvbuf (3) ...). Se i file non sono enormi e potrebbero integrarsi completamente nella cache della pagina (ad esempio se la maggior parte dei file ha qualche gigabyte) le cose potrebbero essere diverse.
BTW, su Linux, potresti essere interessato a chiamate di sistema come posix_fadvise (2) e / o readahead (2) . Se utilizzati correttamente, potrebbero migliorare le prestazioni generali. E sembra che tu stia reinventando il csplit (1) o split (1) . Perché non sono abbastanza per le tue esigenze? Inoltre, perché devi ottimizzare così tanto (ricorda che il tempo del tuo sviluppatore costa più del computer su cui è in esecuzione il tuo programma).
Sei interessato a dividere un migliaio di file al giorno di qualche gigabyte ciascuno o a dividere una dozzina di file al giorno ciascuno di almeno centinaia di gigabyte? Questi sono due problemi diversi! (Suppongo tu abbia un desktop normale). E da dove provengono questi file? Come stanno atterrando sul tuo disco? Quali tecnologie disco e file system (SSD, dischi rigidi rotanti, filesystem remoti)?
PS. Sono sorpreso dalla tua domanda. Dividere un file testuale (ad esempio migliaia di righe) non dovrebbe essere un problema e può essere codificato in modo soddisfacente in modo soddisfacente (a condizione che i buffer siano abbastanza grandi). Non riesco a immaginare una situazione in cui una prestazione così articolata sia importante (al punto da giustificare diversi giorni di lavoro). Devi spiegare il tuo contesto e motivarlo molto di più. Ovviamente la dimensione dei byte è importante!