Große Datenmengen effizient programmieren

Bitte aktiviere JavaScript!
3 int+DateTime bestehend(2*4)+8=16 Byte
Soll das eine Rechnung auf Java-Ebene sein? Da muss man die gänzlich anders berechnen, sie zB meinen Beitrag, der sich mit deinem überschnitten hat ;)



Dennoch würde ich die Pufferung nicht an das System abgeben, sondern selbst machen.
In welchem Beispiel siehst du Pufferung durchs System?
In meinem vielleicht impliziert durch den Stream, aber auf der Ebene würde man sowieso nicht selbst puffen. In dem anderen Beispiel könnte man es als Puffern bezeichnen, allerdings hat das nicht wirklich was mit Streaming zu tun, wenn alles in ein Array gelesen wird, bevor was anderes passiert.


Ich bin immer noch eher in der Auffassung verhaftet, dass man nur über Dinge iterieren sollte, die im Speicher sind. Jedenfalls bei Java. Es gibt zwar Streamdeitoren, die würde ich aber nicht typisch für das Java-Konzept sehen.
Alle InputStreams und Reader in Java funktionieren so - sie lesen nur jeweils einen begrenzten Teil und nicht ganze Dateien in einem Rutsch (außer die Datei ist klein genug, zB kleiner als der Puffer beim BufferedInputStream)
 
Ich sage schon mal vielen Dank für die lebhafte Diskussion, da kann jeder etwas lernen ;)
Feedback von mir wird aber dauern, da ich aktuell nicht allzu viel zeit habe....
Aber das hindert euch natürlich nicht hier weiter zu diskutieren :)
 
Überprüft doch einfach mal die Speichernutzung:
Und da kommt dann was bei raus?

Das Objekte in diesem Fall nicht mehr, eher weniger, Platz brauchen als Arrays, hab ich doch extra detailliert vorgerechnet.

Wenn dir das nicht reicht gibts auch noch 'nen Benchmark dazu (im wesentlichen dein Code, und int[] durch Tick ersetzt), kommt das bei raus:

Code:
Benchmark                                                  Mode  Cnt        Score        Error   Units
AktienBenchmark.intArray                                   avgt   20  1356949,644 ±  18142,629   ns/op
AktienBenchmark.intArray:·gc.alloc.rate                    avgt   20     1016,320 ±     17,345  MB/sec
AktienBenchmark.intArray:·gc.alloc.rate.norm               avgt   20  3401686,609 ±    151,942    B/op
AktienBenchmark.tick                                       avgt   20  1329285,886 ±   9449,018   ns/op
AktienBenchmark.tick:·gc.alloc.rate                        avgt   20     1039,001 ±     10,755  MB/sec
AktienBenchmark.tick:·gc.alloc.rate.norm                   avgt   20  3392785,908 ±    170,487    B/op
Mit Objekten also nicht nur theoretisch, sondern auch real besser.
Der Unterschied zwischen beiden sind (Fehler außer acht gelassen) in diesem Fall 8.900 Byte, was ziemlich genau dem rechnerischen Unterschied von 8896 Byte entspricht, die fehlenden 6 Byte sind der Messungenauigkeit geschuldet.


Und mit dem Benchmark hat man auch gleich die Laufzeiten verglichen, mit Objekten braucht weder mehr Speicherplatz noch mehr Zeit als mit Arrays :)
 
Ich weiß gar nich was du da getestet hast, aber bestimmt nicht das richtige
Benchmark findest du hier: https://gitlab.com/mrBrown/benchmarks

Wie gesagt, entspricht deinem Code, nur das int[] durch Tick ersetzt wurde. Der Benchmark ist sicher nicht der beste, du darfst den also gerne verbessern :)
Für diese Problemstellung ist er aber vermutlich gut genug, da der Code in beiden nahezu äquivalent ist, und das Ergebnis weicht auch nicht vom erwarteten ab.
 
Es ging erstmal nicht um Zeit sondern um Speicher.
Wenn du das einfach mal ausführen würdest, würdest du sehen, dass es auch den Speicherverbauch misst :)

Ich hätte ja gedacht, dass "gc", "alloc" und "MB"/"B" Hinweise genug sind, dass es sich auf den Speicher und nicht auf die Zeit bezieht...
gc.alloc.rate ist die Angabe des während des Benchmarks alloziierten Speichers in MB/sec, gc.alloc.rate.norm ist das ganze normalisiert in B/op.

Dachtest du wirklich, die Zeit wird in MB gemessen?
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben