Hey guys!
I just want to ask you whether you agree with this or not!
Does Houdini need to be more faster than what it is now or not?
I am asking this because I feel Houdini still needs to be more performant.
For example:
- Stroke node is laggy while in real-time!
- Dropping down RBD Material Fracture takes about 10 seconds on a six core machine to prepare (depends on your machine it takes more or less)!
- Removing a bypassed node at the cost of recooking node network!
- Slow for-each node even using within compiled sops!
And probably many more things…

Nobody hasn't any suggestions?

What do you want us to say? Yes? No? How does that help?

Put in a specific support request with sidefx, that will actually put focus on issues. If many people report on the same thing, it gets pushed up the priority list.

You'd need to audit how its made to get answers.

Thank you dears @mestela and @cpb for your responses!
I mean that do you agree that Houdini's cooking system should be faster?
Side Effects developers will see this topic and they will know what you think BTW I will submit an RFE for this.

Yep its nowhere near as fast as it could be on modern hardware. However speed clearly isn't their priority, so sending ‘make it faster’ RFEs may be futile unless you have a lot of clout.

If you foresee Houdini burning you on an upcoming project I'd suggest shop-around, find a faster solution, save yourself a lot of frustration. Beware of false-economy though.

Moin,

I don't understand the content of this thread:

> I mean that do you agree that Houdini's cooking system should be faster?

… what exactly do you mean by that statement? The “cooking system should be faster” has no technical meaning - if by “cooking system” you mean that Houdini “cooks” (compiles and/or executes) “nodes” (or functions) when necessary. There is no “faster” to this, except for “more often” (which you probably don't mean) or “within shorter reaction times” (near real time reaction?), which most likely would only result in milliseconds earlier cooking start.

If you are talking about the compilation of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with.

If you are talking about execution times of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with. Keep in mind that a compiled VEX node has a different performance footprint to those horrible, ban-deserving, patience-killing Python-nodes. Unfortunately, nowadays more and more features all over the world are being done in Python making everything slower and more error-prone. But that's a different topic altogether, for there are evangelists for Python out there one just does not want to mess with.

If you are talking about simulations - please do say so. Please point out exactly what specific situation you have in mind and also show your performance metering showing WHERE things go slow and where things go fast. Houdini provides the tools to do that, use them, please.

Let me just pick this line of yours:

> Dropping down RBD Material Fracture takes about 10 seconds on a six core machine to prepare (depends on your machine it takes more or less)!

… you are already stating that “it takes more or less on different machines” - so what's your claim then? If your hardware isn't up to your demands, why not start there?
I am running a five-years old quadcore machine here that is nowhere near “top nodge” and just dropped down an rbdmaterialfracture node. It took 1.5 seconds (one point five seconds) - which, too, is a completely non-informative thing to say. It has NO MEANING. What has meaning is: What happens in the background? What is DONE when you drop down a node?

For sure, a lot of functions in Houdini could benefit from an overhaul, no doubt, maybe some need a “rewrite from scratch”. But simply saying “Houdini needs to be more faster” (I like that phrasing) is the same as saying “me wife needs to be more prettier”. At least for the latter man invented alcohol.


Marc

P.S. Don't get me wrong. I want things to be faster all the time. If I can endure a Youtube video, chances are that I play it back at 2.0 speed because people simply talk WAY TOO SLOW in order to make more money. But you really need to be specific, you need to do some basic research about what is HAPPENING and then send RFE to SideFX to help them understand your usecase and maybe even come up with solutions for your specific needs. They are QUITE GOOD at that. They actually care. Just give them a chance to help you - by being constructive.

All right first of all thanks guys for the participation!

Moin,

I don't understand the content of this thread:

> I mean that do you agree that Houdini's cooking system should be faster?

… what exactly do you mean by that statement? The “cooking system should be faster” has no technical meaning - if by “cooking system” you mean that Houdini “cooks” (compiles and/or executes) “nodes” (or functions) when necessary. There is no “faster” to this, except for “more often” (which you probably don't mean) or “within shorter reaction times” (near real time reaction?), which most likely would only result in milliseconds earlier cooking start

If you are talking about the compilation of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with.

If you are talking about execution times of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with. Keep in mind that a compiled VEX node has a different performance footprint to those horrible, ban-deserving, patience-killing Python-nodes. Unfortunately, nowadays more and more features all over the world are being done in Python making everything slower and more error-prone. But that's a different topic altogether, for there are evangelists for Python out there one just does not want to mess with.

If you are talking about simulations - please do say so. Please point out exactly what specific situation you have in mind and also show your performance metering showing WHERE things go slow and where things go fast. Houdini provides the tools to do that, use them, please.

Let me just pick this line of yours:

> Dropping down RBD Material Fracture takes about 10 seconds on a six core machine to prepare (depends on your machine it takes more or less)!

… you are already stating that “it takes more or less on different machines” - so what's your claim then? If your hardware isn't up to your demands, why not start there?
I am running a five-years old quadcore machine here that is nowhere near “top nodge” and just dropped down an rbdmaterialfracture node. It took 1.5 seconds (one point five seconds) - which, too, is a completely non-informative thing to say. It has NO MEANING. What has meaning is: What happens in the background? What is DONE when you drop down a node?

For sure, a lot of functions in Houdini could benefit from an overhaul, no doubt, maybe some need a “rewrite from scratch”. But simply saying “Houdini needs to be more faster” (I like that phrasing) is the same as saying “me wife needs to be more prettier”. At least for the latter man invented alcohol.


Marc

P.S. Don't get me wrong. I want things to be faster all the time. If I can endure a Youtube video, chances are that I play it back at 2.0 speed because people simply talk WAY TOO SLOW in order to make more money. But you really need to be specific, you need to do some basic research about what is HAPPENING and then send RFE to SideFX to help them understand your usecase and maybe even come up with solutions for your specific needs. They are QUITE GOOD at that. They actually care. Just give them a chance to help you - by being constructive.

I mean the system on top which passes the information from node to node should be more intelligent in order to designate which node should be cooked and which one is not.
As I said earlier removing bypassed nodes force Houdini to recooke the network also Performance Monitor pane shows 0.001 ms for each of these bypassed nodes which is weird and this can be more painful if you loose the hole simulation cache by just deleting a bypassed node!
Now consider following HIP file before Houdini 18 if you wanted to copy different objects on points you should use for each loop explicitly in SOP whereas in Houdini 18 you can use variant attribute to do so.
But there are huge performance differences between these two methods!
So why for each loops are slow even within compiled block?
What kind of section these type of problems are related to? The system on top which asks each node to cooke or it just related to each node itself?
Thank you so much!

It's slow in your example because you are iterating over each of the 500k points instead of per variant ( check out attached hip )

The reason people stay away from these kind of threads is that they usually stem from someone's frustration, rather than the search for help. It also tends to end in heated, almost religious debates and a thread lockdown.

You really need to specify what your problem is in order to get advice.

“this thing (node/setup) is slow”
- am I doing it wrong? -> check out the docs, look in the forums, then if everything fails ask in the forums for advice
- this is the “official” way to do it, but can it be faster ? -> ask in the forums. Maybe someone has some tricks up their sleeves or there is a different way to tackle your problem.
- this thing is unexpectedly slow -> Maybe it's a bug ? check out forums, submit a bug to sidefx
- this thing is actually slow -> submit a RFE, maybe an example of a DCC that handles this in a better way

Btw: here's a recent example of how a too slow stroke sop led to an amazing, creative workaround:
https://ihoudini.blogspot.com/2020/01/drawing-with-wacom-in-houdini.html [ihoudini.blogspot.com]

blackpixel
It's slow in your example because you are iterating over each of the 500k points instead of per variant ( check out attached hip )

The reason people stay away from these kind of threads is that they usually are the source of someone's frustration, rather than the search for help. It also tends to end in heated, almost religous debates and a thread lockdown.

You really need to specify what your problem is in order to get advice.

“this thing (node/setup) is slow”
- am I doing it wrong? -> check out the docs, look in the forums, then if everything fails ask in the forums for advice
- this is the “official” way to do it, but can it be faster ? -> ask in the forums. Maybe someone has some tricks up their sleeves or there is a different way to tackle your problem.
- this thing is unexpectedly slow -> Maybe it's a bug ? check out forums, submit a bug to sidefx
- this thing is actually slow -> submit a RFE, maybe an example of a DCC that handles this in a better way

Thank you dear Mariusz!
This was really great!
I will create separate topic for each problem.
Really thanks guys for your great helps
and patient!

blackpixel
Btw: here's a recent example of how a too slow stroke sop led to an amazing, creative workaround:
https://ihoudini.blogspot.com/2020/01/drawing-with-wacom-in-houdini.html [ihoudini.blogspot.com]

Amazing!
Thank you so much dear Mariusz!