2012-07-09 12 views
7

Ho un dubbio piuttosto semplice. Spesso, devo scrivere app che usano l'I/O di file bufferizzato e ogni volta che mi trovo di fronte al dilemma di scegliere la dimensione del buffer e finisco spesso per fare tentativi ed errori con risultati piuttosto sgradevoli. Voglio sapere se esiste un metodo o un algoritmo che può determinare automaticamente la dimensione ottimale del buffer per il lavoro in base alla piattaforma sottostante come fa Teracopy quando gestisce i file in Windows. Uso principalmente Qt per la GUI.Selezione automatica della dimensione del buffer per I/O file

Se possibile, un piccolo esempio in C/C++/C#/Java è molto apprezzato!

Grazie!

risposta

15

In Java il valore ottimale è in genere attorno alla dimensione della cache L1, che in genere è di 32 KB. In Java, almeno la scelta di 1024 byte o 1 MB non fa molta differenza (< 20%)

Se stai leggendo i dati in sequenza, in genere il tuo sistema operativo è abbastanza intelligente da rilevare questo e precaricare i dati per te.

Quello che puoi fare è il seguente. Questo test sembra mostrare una differenza significativa nelle dimensioni dei blocchi utilizzati.

public static void main(String... args) throws IOException { 
    for (int i = 512; i <= 2 * 1024 * 1024; i *= 2) 
     readWrite(i); 
} 

private static void readWrite(int blockSize) throws IOException { 
    ByteBuffer bb = ByteBuffer.allocateDirect(blockSize); 
    long start = System.nanoTime(); 
    FileChannel out = new FileOutputStream("deleteme.dat").getChannel(); 
    for (int i = 0; i < (1024 << 20); i += blockSize) { 
     bb.clear(); 
     while (bb.remaining() > 0) 
      if (out.write(bb) < 1) throw new AssertionError(); 
    } 
    out.close(); 
    long mid = System.nanoTime(); 
    FileChannel in = new FileInputStream("deleteme.dat").getChannel(); 
    for (int i = 0; i < (1024 << 20); i += blockSize) { 
     bb.clear(); 
     while (bb.remaining() > 0) 
      if (in.read(bb) < 1) throw new AssertionError(); 
    } 
    in.close(); 
    long end = System.nanoTime(); 
    System.out.printf("With %.1f KB block size write speed %.1f MB/s, read speed %.1f MB/s%n", 
      blockSize/1024.0, 1024 * 1e9/(mid - start), 1024 * 1e9/(end - mid)); 
} 

stampe

With 0.5 KB block size write speed 96.6 MB/s, read speed 169.7 MB/s 
With 1.0 KB block size write speed 154.2 MB/s, read speed 312.2 MB/s 
With 2.0 KB block size write speed 201.5 MB/s, read speed 438.7 MB/s 
With 4.0 KB block size write speed 288.0 MB/s, read speed 733.9 MB/s 
With 8.0 KB block size write speed 318.4 MB/s, read speed 711.8 MB/s 
With 16.0 KB block size write speed 540.6 MB/s, read speed 1263.7 MB/s 
With 32.0 KB block size write speed 726.0 MB/s, read speed 1370.9 MB/s 
With 64.0 KB block size write speed 801.8 MB/s, read speed 1536.5 MB/s 
With 128.0 KB block size write speed 857.5 MB/s, read speed 1539.6 MB/s 
With 256.0 KB block size write speed 794.0 MB/s, read speed 1781.0 MB/s 
With 512.0 KB block size write speed 676.2 MB/s, read speed 1221.4 MB/s 
With 1024.0 KB block size write speed 886.3 MB/s, read speed 1501.5 MB/s 
With 2048.0 KB block size write speed 784.7 MB/s, read speed 1544.9 MB/s 

Che questo test non mostra è che il disco rigido supporta solo 60 MB/s di lettura e/s scrive 40 MB. Tutto quello che stai testando è la velocità dentro e fuori dalla cache. Se questa era la tua unica priorità, dovresti usare un file mappato in memoria.

int blockSize = 32 * 1024; 
ByteBuffer bb = ByteBuffer.allocateDirect(blockSize); 
FileChannel out = new FileOutputStream("deleteme.dat").getChannel(); 
for (int i = 0; i < (1024 << 20); i += blockSize) { 
    bb.clear(); 
    while (bb.remaining() > 0) 
     if (out.write(bb) < 1) throw new AssertionError(); 
} 
out.close(); 

long start = System.nanoTime(); 
FileChannel in = new FileInputStream("deleteme.dat").getChannel(); 
MappedByteBuffer map = in.map(FileChannel.MapMode.READ_ONLY, 0, in.size()); 
in.close(); 
long end = System.nanoTime(); 
System.out.printf("Mapped file at a rate of %.1f MB/s%n", 
     1024 * 1e9/(end - start)); 

stampe

Mapped file at a rate of 589885.5 MB/s 

Questo è così veloce perché le mappe solo i dati nella cache del disco del sistema operativo direttamente nella memoria dell'applicazione (quindi non la copia è richiesta)

+0

Puri awesomeness !!! Questo è quasi come in Java ... ma non so fino a che punto posso implementarlo in C/C++ poiché la maggior parte delle mie app sono native e devono essere il più veloci possibile. Un'altra cosa: il tuo metodo è buono per le app che operano sui dati prima di scriverli (app di crittografia) ?? BTW, Math.pow ("Grazie !!!!", (10/0)); –

+0

applicazioni di crittografia, come la maggior parte delle app che elaborano, i dati sono probabilmente vincolati alla CPU. In questo caso, è improbabile che le dimensioni del buffer siano importanti perché il costo della CPU è così elevato. Le dimensioni delle tue cache potrebbero fare più differenza. IMHO Tutto ciò che puoi fare in Java puoi farlo in C o C++. –

+1

Vedi buona spiegazione, io faccio +1 – aswzen

1

ho vedere questo codice in C:

#include <sys/types.h> 
#include <sys/stat.h> 
#include <unistd.h> 
#include <stdio.h> 

int main() 
{ 
    struct stat fi; 
    stat("/", &fi); 
    printf("%d\n", fi.st_blksize); 
    return 0; 
} 

Restituisce la dimensione del blocco ottimale. Devi usarlo per farlo. Uso la sorgente del flusso verso la destinazione con dimensioni di blocco di 16 * per ottenere prestazioni ottimali. Perché questo test rivelerà il meglio con un PC inattivo con alcuni hardware/OS. Ma non nel caso reale.

Problemi correlati