Prestazioni di lettura file binari .NET

Question

Possiedo un insieme molto grande di file binari in cui diverse migliaia di frame grezzi di video vengono letti e elaborati in sequenza, e ora sto cercando di ottimizzarlo in quanto sembra essere più legato alla CPU di I/O-bound.

I telai sono attualmente in fase di lettura in questo modo, e ho il sospetto questo è il più grande colpevole:

private byte[] frameBuf; 
BinaryReader binRead = new BinaryReader(FS); 

// Initialize a new buffer of sizeof(frame) 
frameBuf = new byte[VARIABLE_BUFFER_SIZE]; 
//Read sizeof(frame) bytes from the file 
frameBuf = binRead.ReadBytes(VARIABLE_BUFFER_SIZE); 

farebbe molta differenza in .NET per ri-organizzare l'I/O di evitare creando tutti questi nuovi array di byte con ogni frame?

La mia comprensione del meccanismo di allocazione della memoria di .NET è debole poiché provengo da uno sfondo puro C/C++. La mia idea è di riscrivere questo per condividere una classe di buffer statico che contiene un buffer condiviso molto grande con un intero che tiene traccia delle dimensioni effettive del frame, ma adoro la semplicità e la leggibilità dell'attuale implementazione e preferisco tenerlo se il CLR lo gestisce già in un modo che non conosco.

Qualsiasi input sarebbe molto apprezzato.

Answer 1

Non è necessario eseguire frameBuf se si utilizza binRead.ReadBytes - si otterrà un nuovo array di byte che sovrascriverà quello appena creato. Questo però crea una nuova matrice per ogni lettura.

Se si desidera evitare la creazione di un gruppo di matrici di byte, è possibile utilizzare binRead.Read, che inserirà i byte in una matrice fornita dall'utente. Se altri thread stanno usando l'array, vedranno comunque il suo contenuto cambiare di fronte a loro. Assicurati di poter garantire che hai finito con il buffer prima di riutilizzarlo.

Answer 2

È necessario fare attenzione qui. È molto facile ottenere risultati di test fittizi su codice come questo, risultati che non vengono mai riprodotti in modo reale. Il problema è la cache del file system, che memorizzerà nella cache i dati letti da un file. Il problema inizia quando si esegue il test più e più volte, modificando il codice e cercando miglioramenti.

La seconda volta e le volte successive si esegue il test, i dati non vengono più fuori dal disco. È ancora presente nella cache, richiede solo una copia da memoria per accedere al tuo programma. È molto veloce, un microsecondo o più di overhead più il tempo necessario per copiare. Che funziona a velocità di bus, almeno 5 gigabyte al secondo su macchine moderne.

Il test rivelerà ora che trascorri molto tempo ad allocare il buffer e ad elaborare i dati, relativi alla quantità di tempo trascorso nella lettura dei dati.

Questo raramente si ripro in uso reale. I dati non saranno ancora nella cache, ora il disco rigido deve cercare i dati (molti millisecondi) e deve essere letto dal disco (un paio di dozzine di megabyte al secondo, nel migliore dei casi). La lettura dei dati richiede ora più di tre o quattro magnitudini di tempo. Se sei riuscito a fare il passo di elaborazione due volte più velocemente, il tuo programma funzionerà solo dello 0,05% più velocemente. Prendere o lasciare.