Ablaufinvarianz, Ausführung als Ablaufinvariante VI's |
Ablaufinvarianz, Ausführung als Ablaufinvariante VI's |
24. Jul 2014, 09:25
Post
#1
|
|
new Member Group: Members Posts: 6 Joined: 20.05.2010 Member No.: 150 LV Version: 8.6 Zertifizierung: keine LV User seit: 2008 |
Hallo zusammen,
was würde denn dagegen sprechen, die VI's aus dem Toolkit Ablaufinvariant auszuführen? Somit könnte man ja durch entsprechende Parallelverarbeitung deutlich an Leistun gewinnen. Gruß |
|
|
24. Jul 2014, 17:05
Post
#2
|
|
proven Member Group: Administrators Posts: 315 Joined: 16.10.2006 From: Düsseldorf Member No.: 2 LV Version: current Zertifizierung: CLA LV User seit: 2001 |
kommt drauf an wieviel SQL-Queries die ADO-Verbindung parallel verarbeiten kann. Probieren kann nicht schaden, aber es kann auch sein, dass es nicht wirklich was bringt, weil die "Bremse" der ADO-Treiber ist und nicht der LabVIEW-Code, der die ADO-Methoden aufruft ...
Die unterste Schicht des ADO-Toolkits (die "API") ist auf jeden Fall so programmiert, dass parallele Aufrufe der High-Level VIs keinen Schaden anrichten können, nur das "API-VI" muss so bleiben wie es ist ... viele Grüße cb -------------------- künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip |
|
|
25. Jul 2014, 09:50
Post
#3
|
|
new Member Group: Members Posts: 6 Joined: 20.05.2010 Member No.: 150 LV Version: 8.6 Zertifizierung: keine LV User seit: 2008 |
Habe es gerade mal versucht. Der Unterschied scheint marginal zu sein. Ich habe rund 5% Verbesserung. Wobei es sehr stark von der Anwendung abhängt. Zum Teil bringt es auch gar keine Verbesserung.
Gibt es denn eine schnellere Variante wie das ADO? This post has been edited by Whiteman: 25. Jul 2014, 10:58 |
|
|
28. Jul 2014, 20:49
Post
#4
|
|
proven Member Group: Administrators Posts: 315 Joined: 16.10.2006 From: Düsseldorf Member No.: 2 LV Version: current Zertifizierung: CLA LV User seit: 2001 |
Habe es gerade mal versucht. Der Unterschied scheint marginal zu sein. Ich habe rund 5% Verbesserung. Wobei es sehr stark von der Anwendung abhängt. Zum Teil bringt es auch gar keine Verbesserung. Gibt es denn eine schnellere Variante wie das ADO? keine Ahnung, vielleicht ist .NET schneller, aber dafür müsste man das ganze ADO-Tool nach .NET portieren um es raus zu finden. Am schnellsten wären vermutlich direkte Zugriffe per TCP auf einen DB-Server, der Stored Procedures abarbeitet, aber auch da müsste man viel Aufwand reinstecken um das umzusetzen. Das schnellste wird vermutlich sein, die Daten, die man wirklich rasend schnell braucht im eigenen Programm im Hauptspeicher zu halten, alles andere wird durch Treiber-Aufrufe etc. immer deutlich langsamer sein ... viele Grüße cb -------------------- künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip |
|
|
Lo-Fi Version | Time is now: 07.08.2024 - 09:07 |