I have a patch (with lots of subpatches) that runs way too slowly to my impression on Win7 64bit on an i7 CPU.
I was using debug mode to find out what I am doing wrong, and one of the subpatches returned > 1000 ‘ticks’, and when digging deeper I found out that it was the Info node using > 750 ‘ticks’, which is 10 to 20 times more than any other node in the patch.
This Info node gets the size for a spread of 16 textures, and this input spread is the result of a selection from different texture spreads (FileTexture, Video, DynamicTexture, GDITexture, …).
Anyway, I am surprised by this and I think this is one of the main reasons for the bad performance. Anyone have any ideas why this happens?
A renderer and a bulk of texture fx generally makes it happen (put a chain of 7-8 of those). Quite hard to have it reproduced since it a bit random.
But looking at it it seems it’s just the timing which is wrong (like even if you remove all info nodes framerate stays the same), so looks like info takes over from renderer timing.
as vux already pointed out, the timing you see is misleading here. the timing you see on the info node is actually the sum of all the timings from the upstream nodes participating in the computation of the resource. let me try to explain:
when vvvv evaluates the graph it measures execution time for each node separately during the evaluation phase but misses to do so when a node asks for device resources, like textures, as the data flow is different. normally data flows top down, but in case of device resources only “functions” flow top down, the actual data flows later when a downstream node like info, pipet or a renderer calls those retrieved functions. those functions take a device as parameter and return a resource for it. to avoid doing computations twice those functions cache their results.
in this specific case here, the info node calls those functions before the renderer, therefor it takes the hit in terms of execution time, as the first call does all the computation whereas the second call by the renderer is a simple look up.
solution would be to “wrap” those functions in debug mode, so execution time could be measured for each node separately. but as of yet there are no plans to do so.
Tis a shame though, that something as (seemingly) straightforward as identifying the format and dimensions of a texture can be so resource hungry that having more than a ‘few’ considerably affects performance.
@mrboni - did you read Elias post asking you if you read the previous post explaining the timing is misleading and everything’s fine with the info node?
What evidence do you have of the info node being ‘hungry’? You can’t base it on the number of ticks it can show during debug mode due to this being a misleading figure as described by Elias.
@mrboni: i know you and youre some sort of content guy, arent you? like interested in content and stuff. if this is the case you typically not only use info nodes but also actually use the content of that texture and render it somewhere, dont you? if this is the case then it is save to say that the info node is not the problem.
if you would however create resources to only get their properties and settings without really looking at the content. then i would say info node is doing to much, since no one is interested in the content and the info node could just skip that part.
i dont see any application where that would be the case; so, like elias said, the info node just does some work that afterwards doesnt have to be done by the renderer or other consumers anylonger, since the info node already took his courage in both hands and already did that work that doesn’t have to be done by others making them faster since they dont have to do it anylonger since the info node already did it and therefore took longer…
