Geschwindigkeitsproblem: großes array an trigger teilen und sortieren

@unicorn
Danke für die Information. Du hattest ja am Anfang schon gesagt, daß sich an dem von tinger selbst vorgeschlagenen Splitting nicht mehr viel verbessern lässt - dem stimme ich zu.
Alledings sollte man das ganze Konzept mal auf den Prüfstand stellen, und da sind zwei Verbesserungen vorstellbar:[list=1]
[*]Die Datenerfasssung wird ja von der Karte selbst organisiert, d.h die CPU des PCs wird in dieser ganzen Zeit kaum belastet. Es läge doch nahe, mit dem Ordnen schon zu beginnen, wenn die Datenerfassung läuft und nicht erst, wenn 6 Millionen Daten angefallen sind. Genau für so ein Pipelining sind doch Queues schließlich da!<>
[*]Die Karten haben doch selbst immer komfortable interne und externe Triggermöglichkeiten. Sollte es da wirklich nicht möglich sein, bereits die Datenerfassung selbst so zu triggern, daß das Problem mit dem Triggerpunkt mitten in einem gelesenen Daten-Array gar nicht erst entsteht? tinger sagt zwar, das sei nicht möglich, aber ganz glauben kann ich es nicht.<>
[st]Mir fällt da doch noch ein Verbesserung ein: ich habe festgestellt, daß Ques langsam sind, wenn man als Datenelemente Arrays verwendet. Der Grund ist, daß jedes einzelne Array in der Queue intern geclustert werden muß. Besser ist es allemal, die Queue statt mit Arrays mit Einzelwerten füttern - also die Arrays in einer for Schleife zu indizieren und in der Schleife alle Elemente der Queue als Einzelelemente hinzufügen.
Die ganze Sortierung könnte dann grundlegend anders organisiert werden.