I noticed this:
I had to subdivide a group of 261k prims, which is part of a 2.5millions prims geometry.
I tried to specify the group name in the subdivide node, but after 1.5 hours (!!) of cooking, I gave up and killed the cooking… Too much time for only 261k prims (and only depth 1 subdivision).

So I tried separate the group of prims, by blasting it from the rest of the geo. I run the subdivide again, and the cooking time was now reasonable (few seconds vs 1.5+ hours).
Then I merged back the two geos together.

My question: is this an overall good practice for better efficiency that should be used with other nodes too, when u want to run a node only on a selected group of prims?

To note: the crazy slowness happened with the Houdini Catmull-Clark algorithm. Other subdivide algorithms had a reasonable cooking time when I specified the group name.

Send it into SESI support - there are code paths, or bugs, in the nodes that can be accelerated/fixed based on specific use cases.

Hello Fuos thanks for the tip,
I just sent a support request to SESI after further testing.

I will report what the support team say, but so far I noticed this:
The houdini catmull-clark algorithm struggles when it is applied to a GROUP of prims, probably for its unique ability of closing the produced holes (which is why I need to use the specific algorithm).

In my case it became super slow because my geo is composed by different not connected pieces. A workaround I found is to run the subdivision inside a “for each connected piece” for loop.

I uploaded the hip file in case anybody wants to test.
Cheers