via Gordon Price. Check out his great Revit deployment course on Udemy here.
“with WU1 for 2014 out, and odd, I thought I would let you know I have tested it using the standard WU recipe, and it works fine. It requires access to the initial deployment to run silently, which is different from previous Revit web updates. And so far as I can tell there is no command line switch to tell it where to find the deployment. We shall see if this is the new (and bad!) way of doing things, or just a one time anomaly.”
An announcement was made recently on the “Revit Deployment & Management for Medium Sized Offices” Udemy course (see here for more info):
We seem to have just discovered an interesting “bug” in Deployments as they relate to Revit Server. The Rollout Tool offers at least a partial solution, but I would like to collaborate with an office or two who are using Revit Server, and prioritize any additions to the script. If you are using Revit Server, and can spare a little time to discuss the issue and how it might impact your specific configuration, and what the Rollouts can do to help, please email me directly (email hidden). I’ll schedule a GotoMeeting for some time that works for you and we can proceed from there. Thanks!
Until we have full multi-core implementation on Revit, it is essentially looking at one core at a time (except for certain uses, such as Rendering). Mark Cronin has tested whether Hyper Threading helps standard Revit – and his benchmarks indicate that it does not… the number to look at below is 318 (no HT) vs 335 (with HT).
He “averaged the results from the workstation, and the scores can be seen below: They clearly show that there is at least a marginal improvement in the model creation portion of the testing, and a substantial performance reduction in the rendering section with Hyper-Threading disabled.” via Hyper-Threading for Revit? | betterREVIT
How far has multi-core implementation come in Revit? Gordon Price on RFO: File and view open are both multi-threaded, as are exporting of DWGs and images. Pretty sure printing is multi-threaded now too. And I am sure that updating a curtain wall is, just not sure yet if that is a function of curtain walls specifically, or if updating any family in a project is multi-threaded. Pretty sure it is not everything, as I just tested changing a wall thickness and it pegged my dual core VM at 50%. Edits to doors hit 49-50% for just a second. I suspect curtain walls got the optimized code because 1: it was easier and 2: really complex curtain walls kill performance
I recall that the revit.ini used to have a setting for multi-core wall join cleanup. Steve mentions it in quoting a Revit technical note: In Revit 2010, multi-threaded methods for printing and wall join cleanup have been made available. Multi-threaded hidden line removal for printing has been enabled by default. via Revit OpEd: Multi Core/Processors – Tech Note
So the revit.ini used to have ParallelWallJoins and ParallelPrintProcessing switches. I’m not sure if these are still implemented in Revit 2013 (my .ini was at “C:UsersLukeAppDataRoamingAutodeskRevitAutodesk Revit 2013Revit.ini” but didn’t include any lines for these multi-core switches … However, it might still be possible to add them.)
