Laden...

Performantes Caching für float[] aus Stream?

Erstellt von Scanner vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.327 Views
S
Scanner Themenstarter:in
50 Beiträge seit 2006
vor 12 Jahren
Performantes Caching für float[] aus Stream?

Hallo,
ich plane gerade eine Anwendung, die über den TCP/IP Port einen Datenstrom empfangen und die empfangenen Daten mit verschiedenen Algorithmen schrittweise bearbeiten soll.

Bei den Daten handelt es sich auschließlich um float Werte, die auf 32 Kanälen mit je 1000 Werten pro Sekunde hereinkommen. In einer Minute fallen folglich ca. 64 MB zu verarbeitende Daten an. Eine Session dauert ca. 30min, die Datenverarbeitung läuft während der geamten Zeit. Wie schnell die Verarbeitung sein wird, kann ich momentan noch schlecht abschätzen. Für den Vearbeitungsprozess sollen jeweils float[1000] von einem sortierten Cache entnommen werden und dann durch die verschiedenen Algorithmen geschickt werden, das Endergebnis wird auf dem Bildschirm ausgegeben. Wenn ein Datenpaket einmal aus dem Cache entfernt wurde, wird es dorthin auch nicht mehr zurück geschrieben, der Speicher wird dann also frei.

Die Anwendung ist zudem zeitkritisch, die Verarbeitung sollte so schnell wie möglich erfolgen.

Momentan ist für mich mangels Erfahrung unklar, welche Art von Cache ich verwenden soll. Aus Performancegründen gehe ich davon aus, dass der Cache in-memory sein sollte, richtig? Danga Memcached und Microsoft Velocity scheinen nur für größere verteilte Systeme sinnvoll, ein einfaches Dictionary tut es vermutlich wegen der hohen Datenmengen auch nicht? Ich bin bei CodeProject unter Using MemoryCache in .NET 4.0 auf eine Lösung per ObjectCache gestossen, die ganz gut aussieht, jedoch bin ich hier auch unsicher, weil dort per String indexiert wird und Objekte zurück in float konvertiert werden müssen, um sie durch den Algorithmus zu schicken -- das bringt doch sicher nicht notwendige Performanzeinbußen mit sich?

Bin für jeden Ratschlag dankbar, auch was die Architektur und das Threading angeht. Momentan habe ich das Consumer/Producer pattern und Pipes & Filters im Auge. Threading wollte ich mit Wait & Pulse realisieren. Wär gut, wenn mich jemand auf den richtigen Weg bringen oder in meinen Ideen bestätigen könnte. Danke vorab!

1.346 Beiträge seit 2008
vor 12 Jahren

Wo ist denn da ne große Datenmenge? 64mb pro Minute sind doch nicht viel.. (Ich komme beim nachrechnen auch nur auf 7mb/Minute 32(Kanäle) * 1000(Werte) * 4(Bytes bei einem float) * 60(Sekunden in einer Minute) = 7680000 b = 7500 kb = 7,3mb)

Ich verstehe das problem gerade nicht so ganz

S
Scanner Themenstarter:in
50 Beiträge seit 2006
vor 12 Jahren

das problem habe ich oben ausführlich beschrieben. deine antwort enthält weder einen konstruktiven vorschlag noch eine bestätigung.

C
1.214 Beiträge seit 2006
vor 12 Jahren

das problem habe ich oben ausführlich beschrieben. deine antwort enthält weder einen konstruktiven vorschlag noch eine bestätigung.

Doch. Er hat ja richtig gerechnet, wenn deine Angaben stimmen, dann sind es nur 7 MB/min. In 30 Minuten sind es dann unter 250 MB, das ist nicht viel, kannst komplett im RAM halten und dir viel Stress ersparen.

S
Scanner Themenstarter:in
50 Beiträge seit 2006
vor 12 Jahren

wie ich geschrieben habe, ist nicht die datenmenge an sich das problem, sondern die geeigneten techniken bzw. patterns dafür zu finden.

gut, ich liege also mit in-memory richtig. dann bin ich darin schon mal bestätigt, danke. wie ich konkret in diesem fall am besten cache ist mir weiterhin unklar.

1.346 Beiträge seit 2008
vor 12 Jahren

Meinst du vielleicht einen Ringbuffer, bzw eine Queue?

Gelöschter Account
vor 12 Jahren

Es spricht nichts gegen ein Dictionary oder eine beliebige andere Collection aus dem Framework.

Es sei denn du willst wirklich ein verteiltes System aufbauen. Dann wird es komplexer. Rein von der Datenmenge ist es aber nicht weiter tragisch und da du ja sowieso alles in 1000er schritten in separaten Objekten hältst, ist es auf für die "cachenden" Auflistungen kein Problem.

S
Scanner Themenstarter:in
50 Beiträge seit 2006
vor 12 Jahren

Nein, ich baue kein verteiltes System. Mein Problem ist wie gesagt, dass ich hier die schnellste Möglichkeit suche, die Daten zu cachen. Ringbuffer ist natürlich eine weitere Möglichkeit, aber auch hier habe ich keine eigenen Erfahrungswerte, deswegen frage ich ja in einem Forum, um auf andere Erfahrungen zurückgreifen zu können.

Wenn ein Dictionary performant ist und für diese Belastung geeigent ist, ist gut, dann mache ich das so. Die Daten erreichen meinen Client im byte[] Format. Ich hab jetzt an einigen Stellen gelesen, dass man die Daten in dem Format cachen soll, in dem sie auch weiter verarbeitet werden, das wäre in meinem Fall float. Ist es dann am besten, die Daten zu empfangen, dann in float zu wandeln und dann ins Dicctionary zu packen, um sie danach als float in einen Algorithmus stecken zu können?

Gelöschter Account
vor 12 Jahren

Ja

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Scanner,

erstmal ein klarer Fall von "premature optimization is the root of all evil". Die Rechnung von pdelvo belegt, dass hier kein Performance-Problem und die von Coder007, dass auch kein Speicherplatzproblem vorliegt. Also kannst du es im Grunde machen, wie du willst. Eine List<float>, in die du die Werte sequentiell reinschreibst, würde also vollkommen reichen. Da du immer 1000er Päckchen willst, kannst du die mit List<T>.CopyTo problemlos herausholen.

herbivore