2012-07-09 11 views
7

Mam dość podstawową wątpliwość. Często muszę pisać aplikacje, które używają buforowanych plików I/O i za każdym razem, gdy mam do czynienia z dylematem wyboru rozmiaru bufora, kończę na próbach i błędach, często z dość nieprzyjemnymi wynikami. Chcę wiedzieć, czy istnieje jakakolwiek metoda lub algorytm, który może automatycznie określić optymalny rozmiar bufora dla zadania w oparciu o platformę bazową, taką jak Teracopy, podczas obsługi plików w systemie Windows. Używam głównie Qt dla GUI.Automatyczne wybieranie rozmiaru bufora dla pliku I/O

Jeśli to możliwe, bardzo mały przykład w C/C++/C#/Java jest bardzo doceniany!

Dzięki!

Odpowiedz

15

W Javie optymalny jest zwykle w okolicach rozmiaru pamięci podręcznej L1, który zwykle wynosi 32 KB. W Javie przynajmniej wybór 1024 bajtów lub 1 MB nie robi dużej różnicy (< 20%)

Jeśli czytasz dane sekwencyjnie, zazwyczaj twój system operacyjny jest wystarczająco inteligentny, aby to wykryć i wstępnie pobrać dane dla ciebie.

Co możesz zrobić, to: Ten test wydaje się wskazywać na istotną różnicę w stosowanych rozmiarach bloków.

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)); 
} 

drukuje

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 

Co ten test nie pokazuje się, że dysk twardy obsługuje tylko 60 MB/s odczytu i pisze s/40 MB. Wszystko, co testujesz, to szybkość w i z pamięci podręcznej. Jeśli był to twój jedyny priorytet, użyłbyś pliku mapowanego w pamięci.

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)); 

drukuje

Mapped file at a rate of 589885.5 MB/s 

Dzieje się tak szybko, ponieważ to właśnie odwzorowuje dane w pamięci podręcznej dysku OS bezpośrednio do pamięci aplikacji (więc nie jest wymagane kopiowanie)

+0

Czysta Awesomeness !!! To jest prawie bóg jak w Javie ... ale nie wiem, jak daleko mogę to wdrożyć w C/C++, ponieważ większość moich aplikacji jest natywna i musi być tak szybka, jak to tylko możliwe. Jeszcze jedno: czy twoja metoda jest dobra dla aplikacji, które działają na danych przed ich zapisaniem (aplikacje szyfrujące)? BTW, Math.pow ("Thanks !!!!", (10/0)); –

+0

aplikacje szyfrujące, podobnie jak większość aplikacji przetwarzających dane, prawdopodobnie będą obciążone procesorem. W takim przypadku rozmiar bufora jest mało prawdopodobny, ponieważ koszt procesora jest tak wysoki. Rozmiary pamięci podręcznych mogą mieć większe znaczenie. IMHO Wszystko, co możesz zrobić w Javie, możesz zrobić w C lub C++. –

+1

Zobacz dobre wyjaśnienie, robię +1 – aswzen

1

mam zobacz ten kod w 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; 
} 

Zwraca optymalny rozmiar bloku. Musisz tego użyć. Używam źródła strumienia do miejsca docelowego z rozmiarem bloku 16 *, aby uzyskać optymalną wydajność. Ponieważ ten test ujawni się najlepiej z komputerem na biegu jałowym z niektórym sprzętem/systemem operacyjnym. Ale nie prawdziwy przypadek.

Powiązane problemy