I'm not sure if I'm doing something wrong here guys, but I was a little surprised (to say the least) that H12 appears to be so very much slower than H11 with respect to handling large geometry.
Let me explain: I have one particular geometry asset (unavoidably large) which used to take around 27 seconds to instantiate, and around 4 seconds to save after editing - not great, but certainly not frustrating in any way. I now install the same asset with H12 and it takes a whopping….wait for it….4 minutes and 20 seconds to instantiate the operator in the network pane; and around 30 seconds to save.
I have a 16 core machine (2 x hyperthreaded i7 quadcores) running 12 gig of ram. My little 2gb mac mini could instantiate said asset more quickly with H11. I think I must be missing something here chaps
Without posting a scene file showing the issue it makes it very hard to know what your doing in the Network. Have you used the new Performance Monitor * Alt + Y ) to show the cook times for nodes.
Unfortunately, it's too big to upload. I wondered if there might be something under Preferences to take advantage of geo multithreading; but H12 must work with how ever many threads it detects. As i say, with H11 it was fine. So one doesn't have to tweak the settings with H12…then, i guess I'll have live with it. Very disappointing though. I was really hoping the new geo engine would yeild faster results. The asset in question has many thousands of nodes, and there really isn't any way of improving sop cook efficiency, not withou removing the dynamic parenting system. That is the weak link, but given the absence of a dedicated dp system, what is in place is as user-friendly as can be done. Have done extensive research on this. But thanks for responding
Well I think its very important to get to the bottom of this as who knows there may be some bottle neck. Run the performance manager. Pin point what part of your network is slow. Build a simple scalable scene. You know the drill , show the issue as otherwise its all talk. So far in H 12 I am blown away with the performance I am getting over 11 .
Yes, i know the drill. But it seems funny that the only variable here is 12. Will give it a try though. I can see the different networks as they are being cooked…it's just as before but slower. Will let you know how things go.
The bottom line is that not all SOPs were rewritten to work with new library (that's why library has two interfaces afaik, old fashion like and new paradigm). In some cases this round trip compatibility mode slows down Sops considerably. SESI promised to fix these issues one after another when reported by users, thus not taking care of everything at once (not possible), but prioritizing them by user's needs.
Does this asset heavily process geometry or rather it has a lot of expressions/nodes?
Yes to both. Masses of geometry plus a lot and nodes and expressions. On the plus side the python code still works, but very little else does i may have t uninstall and install 11 again just so i can get some work done! Lol
Just reinstalled 11…phew! Super quick again, and the point and color sops are once again working with primitive sphere. As a slight aside, with 12 if you have merged geometry, i noticed the visibility sop only works on the geo from one of the merged inputs and not the sum of all the inputs, i.e. the merged geometry. Odd that..
H12 can certainly be slower than H11, but without a specific test case it's hard for us to try and address your particular case. There are some issues we know about, and are working to address, so you may get lucky if your case falls into one of these.
We would very much like to see this file for our testing. If it is too big to attach, you can try uploading to ftp.sidefx.com and giving us the file name you uploaded? Or make available through any other web-hosting service you wish.
If you don't want it widely available, you can 7zip it with a password, make the password protected file available, and then provide us the password through another channel.
Thanks for that. Yes. I'll upload it as ftp. password protected zip., if that's OK. I've been developing this asset for around two years (you'll see why when you see it!), and whilst there is some way to go before it's completely finished, I'd prefer it not to be freely distributed, as it's for use in a long term project.
Tried accessing the FTP site at sidefx but keep getting the following error:
'You don't have permission to access the requested directory. There is either no index document or the directory is read-protected. You don't have permission to access the requested object. It is either read-protected or not readable by the server.'
There was a problem where we had too small a max user that should be fixed. You also have to cd into the incoming directory to do the upload, not the directory you first start in.
