Hi,
I would like to discuss about tipps how to increase performance. May be some of you gurus have something nice to contribute…
I do start with some I observed - its about using less nodes as possible. My favourite for this is definitely Expr (Value), which also keeps your structure lean.
performance_nodes.v4p (17.2 kB)
the wiki page Performance is supposed to collect this kind of tips. Its great to diskuss things here; but all final tips&tricks should go there.
apart from the fact that debug mode is currently little more helpful than reading chicken bones:
Expr (Value) might keep your structure clean, but can also obfuscate what you’re doing with your data.
when adding up the voodoo in the other example, my machine makes no difference between the two. more importantly, if you’re trying to make a point out of “undynamic static structures are more efficient than flexible solutions in terms of performance”, i’d have to agree if you weren’t talking about vvvv. it is a bad idea to copypaste identical nodes all over your patch, only to go back and rewire yourself into carpal tunnel just for changing some numbers. granted, the fast prototyping nature of vvvv creates an overhead you won’t have when coding the same thing in C++, for example; but it allows you to finish it in a fraction of the time. avoiding spreads & dynamic structures is not the way to remedy your performance problems, because those are the exact features you’re here for in the first place.
Hehe, for me its better to read chicken bones, then just seeing miracles everywhere. I dont know a better way to see where calculation are heavy or not.
I did see differences in my small example, otherwise I wouldnt post it. Might be helpful if some others can report. But that is what this thread is about - talking about this.
Actually, for me performance issues are one of the last parts of coding of course. So, I cant see your comments as a sort of negative critique because I’ve never pointed into that direction. But might also be interesting to discuss how to keep your patch lean, make it easy visually readable, how to comment, how to subpatch…
Btw Ive seen the idea of a Debug-Renderer at Node08 first time and love and use it a lot now.
Btw Ive seen the idea of a Debug-Renderer at Node08 first time and love and use it a lot now.
What do you mean by Debug-Renderer ?
Maybe you could add that information to the Performance page if it’s usefull and/or something not easy to figure when starting with vvvv
@chicken bones; debug mode: i do not really subscribe to the chicken bone theory - its more of a schrödingers cat thing. in fact many of the numbers which are shown in the debug mode actually do correlate to some time measure the nodes take internally to calculate some results, a significant number of nodes and times are not taken into account, and the exact nodes who are not taken into account may change completely by editing small parts of your patch.
So to test how relevant a certain subpatch is in terms of performance, you have to delete it and see what it does to your overall frame rate. Schrödinger didnt put the concept of undo in his story wth the cat, but note that Ctrl+Z is your friend for this technique.
@anachronik: The so called debug renderer is nothing mysterious. Its just an additional renderer window showing some more infos. See attached file.
@oschatz: After overthinking your comment Im not sure why there is a debug mode, if its not reliable at all ;D Please, can you explain more in detail which stuff isnt taken into account - or are this too many/is this too much?
As you know there are always serveral ways of programming to getting your desired result, Im looking for the lightest one. But building up two subpatches and compare them afterwards isnt comfortable as it is taking too much time for dumping a half.
Do you have an idea how I can get performance information during programming decisions - like do I take
debug-renderer.v4p (0 Bytes)