Vvvv performance

vvvv beta general
#1

sorry for the german post…

während dem performanceoptimieren unseres riesenpatch sind wir auf folgendes problem gestossen.

wir berechnen den zustand für 200 leds und senden einen 200 slices grossen spread an msbergers cinetix usb patch. die framerate bricht von ca 36 fps auf 13 fps zusammen.
wenn man aber den 200er spread mittels einem linear spread erzeugt und diesen in das dmxpatch sendet ist überhaupt kein geschwindigkeitseinbruch feststellbar.

seltsam ist auch, dass die framerate sogar zusammenbricht wenn man nur eine iobox an das outlet hängt oder sogar nur mit der maus über das outlet fährt.

wir vermuten, es könnte an der extrem verschachtelten patchtruktur liegen? es sollte ja für die performance eiegtnlich keine rolle spielen woher ob der 200er spread kommt-

woran könnte das liegen, was lässt sich dagegen unternehmen?

das file entzippen und den ordner vbsg in modules ablegen.vbsg data in den vvvv hauptordner ablegen. index.v4p starten.

#2

0 Bytes of course

and i bet, in about 2 hours everything works…

uf wiederluäge
kalle

#3

Sorry, mehrmals probiert
0 Bytes

aber hast Du schon mal den seit 7.4 implemantierten DEBUG mode ausprobiert?
das ist das Werkzeug, mit dem Du es siehst:

geh in deinen Rootpatch und drücke ctrl-F9

dann wird dir vieles klarer

#4

i quickly looked into your patches. very impressed. i do not think its an issue related to the dmx sender.

vvvv currently degrades somehow with the raw number of nodes - quite independent of the actual calculations. having 30 very complex nodes with some hundrets of nodes inside makes the whole patch quite slow.

i dont know much about the actual algorithm you use in the patch, as i didnt got all the relative paths right - but i´d try to have one Linie02 node instead of 30, and doint all things with a spread of the 30 trains. if this would lead to major restructuring efforts, it would also pay to refactor as many of the subpatches within Line02 into spreaded global patches (using inlets, s and r nodes and probably many getslices).

the subpatching itself is quite efficient, but sheer number of nodes you can create by multiplication of the instances makes it slow.

and - did you already checked your patches in debug mode (shift+ctrl+F9)? in debug mode you will see how long each node takes for calculation.
it might pay also to reset the slicecount of certain subgraphs to 1 if they are not used - small spreads are obviously faster.