2013-02-27 7 views
7

Ich habe 8 Dateien. Jeder von ihnen ist etwa 1,7 GB. Ich lese diese Dateien in ein Byte-Array und diese Operation ist schnell genug.BufferedReader in einer Multi-Core-Umgebung

Jede Datei wird dann wie folgt lauten:

BufferedReader br=new BufferedReader(new InputStreamReader(new ByteArrayInputStream(data))); 

Wenn in einem sequentiellen Sinn einen einzigen Kern verarbeitet unter Verwendung es zu vollenden abour 60 Sekunden dauert. Wenn die Berechnung jedoch auf 8 separate Kerne verteilt wird, dauert es viel länger als 60 Sekunden pro Datei.

Da die Daten alle im Speicher sind und keine IO-Operationen ausgeführt werden, hätte ich angenommen, dass es nicht länger als 60 Sekunden dauert, eine einzelne Datei pro Kern zu verarbeiten. Also, die insgesamt 8 Dateien sollten in etwas mehr als 60 Sekunden abgeschlossen sein, aber das ist nicht der Fall.

Fehle ich etwas über BufferedReader-Verhalten? oder irgendeines der Leser, die in dem obigen Code verwendet werden.

Es könnte erwähnenswert, dass ich diesen Code bin mit zum Hochladen von Dateien zuerst:

byte[] content=org.apache.commons.io.FileUtils.readFileToByteArray(new File(filePath)); 

Der Code über alle sieht wie folgt aus:

For each file 
read the file into a byte[] 
add the byte[] to a list 
end For 
For each item in the list 
create a thread and pass a byte[] to it 
end For 
+0

Wie viele Laufwerke sind die Dateien verteilt? Oder sind sie alle auf demselben Laufwerk gespeichert? –

+2

Für solche großen Dateien würde ich dringend die Verwendung von NIO empfehlen. Bitte überprüfen Sie diesen Artikel: http://www.javalobby.org/java/forums/t17036.html, könnte es hilfreich sein – n1ckolas

+0

Dateien sind In-Memory in einem Byte [] gespeichert. Festplattenlaufwerke sind hier nicht relevant. @RJRyV – DotNet

Antwort

3

Wie geht es dir eigentlich „die Berechnung der Verteilung von "? Ist Synchronisation beteiligt? Erstellen Sie einfach 8 Threads, um die 8 Dateien zu lesen?

Auf welcher Plattform laufen Sie (Linux, Windows, etc.)? Ich habe scheinbar seltsames Verhalten vom Windows Scheduler gesehen, bevor es einen einzelnen Prozess von Core zu Core verschiebt, um die Last zwischen den Kernen auszubalancieren. Dies führte zu einer langsameren Leistung, als dass nur ein einzelner Kern mehr genutzt werden konnte als der Rest.

+0

Synchronisation zwischen Objekten war das Problem. Danke Brett. – DotNet

2

Wie viel Speicher schaukelt Ihr System?

8 x 1,7 GB, + Betriebssystem Overhead, könnte bedeuten, dass virtueller Speicher/Paging ins Spiel kommen muss. Das ist offensichtlich viel langsamer als RAM.

Ich schätze Sie sagen, dass jede Datei im Speicher ist, aber haben Sie tatsächlich 16 GB freien RAM oder gibt es mehr auf einer abstrahierten Ebene?

Wenn der Context-Switch auch ständig Seiten wechseln muss, würde das eine längere Zeit erklären.

+0

Danke für Ihre Antwort, ich habe Speicher groß genug, um die Daten unterzubringen. Kein Paging oder Verwendung von virtuellem Speicher ist beteiligt. – DotNet