Jump to content
  • 21
Amorphous

Overhaul Productivity: Reduce Wait Times (Project Sharing Sync, Section Viewports, Verifying File)

Question

17 answers to this question

Recommended Posts

  • 0

It seems VW is a single-core operation most of the time.

 

You can check via (the Mac equivalent) the task manager which reveals the reality, it's practically 99% of the drafting/plan work time at ~ 12.5%. Which is one of eight cores.

2019772921_Singlecore.thumb.PNG.4f70635644a35ba1dd3a8542be664cc1.PNG

 

The code needs updating to utilize modern processors asap.

 

 

  • Like 1

Share this post


Link to post
  • 0

I thought 2019 was advertised as multi threading, but when I leave task manager running on my second monitor I only see it using one? 

  • Like 1

Share this post


Link to post
  • 0

UPDATE: The 'save and commit' speeds are continuing to provide a massive headache for our office....

 

I have just screen-recorded a 'save and commit' process in the following video. You can see in the video the process took around 6:00 minutes. That is twice as long as I thought it was in the posts above. 

 

 

While the 'save and commit' process is in progress, other team members can't do very much on the project, because all changes to the Working File needs 'permission requests' into the Project File.

A project file that is engaged in a 'save and commit' process rejects all 'permission requests'***

 

Lets do some maths here, assume a team of 4 workers.

 

  1. Worker A saves and commits, Workers B, C and D cannot do anything during that process.
    @ 6:00 minutes for the process, that is 4 x 6:00 minutes (total 24 minutes) of lost staff time (man hours) for just one terminal to refresh working file. 
  2. Worker B then saves and commits. That's another 24 minutes of man hours.... etc. etc (repeat four times for four workers)

So, for the project team of four to just have one round of refresh, we lose 96 minutes (1 hour, 36 minutes) of man hours.

 

For reasons I described in another post under 'troubleshooting' forum. It is not possible for us to only do one round of refresh per user per day, as that risks our 'Working Files' to being permanently disconnected from the 'Project File' with irrevocable consequences (work done on say, creating new viewports cannot be simply copied and pasted from one file to another)

 

@Jim Wilson with sincerity, we really do struggle with this issue on a daily basis, and hope you can reflect this to your team and find a quick resolution. We love using Vectorworks and would love that love reciprocated. 

 

------------------------------------------------------------------------

 

***One way around this this 'permission issue' is for other members of the team 'check out' as many items as possible, prior to this 'save and commit'. But this kind of process is impossible to coordinate and plan, as we always need a number of elements as part of the workflow (different 'objects', 'classes', 'layers' 'viewports' etc).

 

  • Like 1
  • Sad 1

Share this post


Link to post
  • 0
On 8/29/2018 at 6:36 PM, Amorphous said:

(B2) OVERHAUL THE VW CODING FOR HIDDEN LINE, PLUS MAKING THIS MULTI-CORE PROCESS

 

  • This seriously needs urgent change. We are always sitting in the office until early hours in the morning to publish

 

  • Remember, the first round of publishing is really just for 'checking and markups'. And if we have to wait around for a few rounds of this. It is neither productive or fun.

 

I think this is a big issue for everyone, even those that don't use project sharing. If you're working form a full 3d model, making any small change means many viewports need updating afterwards. Rendering for check sets (maybe multiple times) and then finally rendering for an issue set can take a lot of time.

 

On 9/21/2018 at 5:38 AM, Patrick Fritsch said:

I thought 2019 was advertised as multi threading, but when I leave task manager running on my second monitor I only see it using one? 

 

I think only Renderworks and the new on demand tessellation features are true multicore. I know geometry calculations are not.

 

Kevin
 

  • Like 4

Share this post


Link to post
  • 0
On 8/30/2018 at 11:36 AM, Amorphous said:

(B1.1) MAKE 'SAVE AND COMMIT' A MULTI-THREAD PROCESS

 

  • In the above example, if we expand the number of team members on a project to 4. A save can commit operation can take 8-12 minutes. 

 

  • This is ridiculous.

 

  • The slowness is not due to the network speeds or computer speeds, it seems to be the sheer amount of processing that is required to process the changes.

 

  • If this operation is a multi-core operation, I would imagine this to be a lot faster. Again this is a MASSIVE productivity issue for our office. 

 

Yes please, even for smaller files it would be a win to offline save, commit and sync.

I mean it's an inherent part of our job to management co-ordination of out of date information both within our teams and at a larger project scale. We can deal with the risk here that is minutes, not days like is common when we deal with other consultants.

 

That said the old model of checking out whole layers seemed problematic it just meant we needed to keep the number of layers we always had for Workgroup Referencing. 

 

Also, In term of streamlining workflow. I think we could add "Updating Story Linked objects" as a background potential operation. Especially given it happens often inside the organisation dialogue while we might be making numerous edits. Slowing down the progress of each edit while waiting for non-visible operations to occur.

Share this post


Link to post
  • 0

The fact that the application uses only single core most of the time is a bit baffling. Would I be off with an old Pentium 4 at 4.4GHz? Or a Core2Duo?  I've invested $500 to a Core i7 processor, the capacity of which I'm using most of the time is only 1/8th.

  • Like 2

Share this post


Link to post
  • 0
On 9/27/2018 at 12:11 AM, JMR said:

The fact that the application uses only single core most of the time is a bit baffling. Would I be off with an old Pentium 4 at 4.4GHz? Or a Core2Duo?  I've invested $500 to a Core i7 processor, the capacity of which I'm using most of the time is only 1/8th.

 

Even a basic step like offlining single threaded operations so the interface gets back to user input would have been a major win and would have set them up to then multi-thread those processes in the background. 

  • Like 1

Share this post


Link to post
  • 0

@Matt Overton @JMR @Kevin McAllister

According to the following post (and various others too), an Upgraded Mac Pro 4,1 or 5,1 is the best Mac Computer you can get on the market right now, beating even the iMac Pro, and I quote:
 

https://create.pro/blog/mac-pro-51-best-system-creative-professionals-2018-internal-expandability-unparalleled-workstation-customisation/

 

'We also found that in testing our Mac Pro 5,1 still continued to beat the iMac Pros graphics computer performance in every test'

 

All of the computer terminals in my office is of the above specification with X5690 processors, SSD/NVMe Drives and RM580 Graphics Cards. In other words, our terminals all have 12-core processors. 

 

However, operating Vectorworks on what is allegedly best Computer Terminals is still slow and laggy.

 

Having fully graded to the best machine of the day, we can only point this lack of productivity in our workflow to one culprit...

 

 

  • Like 1

Share this post


Link to post
  • 0

Per my post above about 'release' in 'project sharing' not working properly.

 

When we 'right click' - 'release' any objects, VW prompts us to 'Cancel', 'Discard' or 'Commit' changes to the file before the 'release' can be done.

 

If we select 'Commit', then the Working File will suddenly disassociate from the Project File.

 

This happens 80% of the time. And then we have to go through the 20-minute exercise of 'let's create a new version' as detailed above.

 

Can someone from Vectorworks please address these very real frustrations we face daily? I feel like we are just users talking amongst ourselves.

Screen Shot 2018-10-08 at 4.28.15 PM.png

Share this post


Link to post
  • 0

We also get this.

 

Very often it occurs when the commit operation crashes while in progress. It occurs also when the "administrator" is not even working on the project.

 

1108074106_2018-08-10Marika-changedpermissions-notreally.thumb.PNG.c5bedc8ec83d75f11597a9f1585f288a.PNG

Share this post


Link to post
  • 0

If you are getting the message the that "The commit operation failed because your permissions were changed..." and you are certain the administrator did not release your objects, could you please send me your PF and WFs (in a state that exhibits this problem) via a private message?

 

Thanks,

Tolu

Share this post


Link to post
  • 0
On 8/29/2018 at 9:36 PM, Amorphous said:

 

(A3) : SLOW WORKSHEET CALCULATIONS 

 

  • We run a full BIM model in our office, so everything, including schedules come from our model.

 

  • We find the process of recalcuations to be extremely slow, especially given the records attached to objects are really simple. This surely can be improved. 

 

(B3) WORKSHEET SPEEDING UP

 

  • We can't comment on how your back end works. But the time taken to calculate the simple information we would like to display seems disproportional.

 

 

 

@Amorphous Improving worksheet recalculation speed is on our radar.

Are you recalculating all worksheets in your file? or just a single worksheet? (Note that there are two 'recalculate' commands; one will update all worksheets in your file and the other will just update the active worksheet). Updating all worksheets in your file will be slower of course.

The recalculation speed is proportional to the file size or the number of objects in the file. The nature of the data to be extracted from the objects also determines the performance.

Do you have a typical file that demonstrates slow worksheet calculations? Please send it to me via private message.

Because slowdowns can be caused by many different factors, it is very helpful to us to see many different examples.

 

 

Share this post


Link to post
  • 0
4 hours ago, Tolu said:

If you are getting the message the that "The commit operation failed because your permissions were changed..." and you are certain the administrator did not release your objects, could you please send me your PF and WFs (in a state that exhibits this problem) via a private message?

 

Thanks,

Tolu

 

Hi Tolu thanks for your reponse. I’ve sent you the file via a PM, but to summarise:

 

Everytime we have a permission issue. We ‘save a new version’. I am up to ‘Version 175’ for one project and ‘Version 59’ for another.

 

We don’t make a record of which version had which type of permission problem, so I can’t send you that PF and WF ‘in that state’ until it next happens.

 

What I can tell you is that the most common permission issue is:

- a user (‘User X’) checks out ‘an item’ in WF

- VW crashes on the computer terminal of ‘User X’

- the ‘item’ checked out by ‘User X’ at the time of the crash presents permission issues

- When anyone (including ‘User X’) tries to edit that said ‘item’ in the file, it says ‘User X’ has the item checked out and thus can’t be edited 

- we have to save a new version to get around this permission issue

- In ArchiCAD, the BIM admin can ‘force’ a user out of the file to resolve permission issues. Would be great to have the same in VW.

Share this post


Link to post
  • 0
2 hours ago, Amorphous said:

We don’t make a record of which version had which type of permission problem, so I can’t send you that PF and WF ‘in that state’ until it next happens.

Understood. Please save the files when next it happens, and send them to me. I can look at the History to determine what happened.

 

2 hours ago, Amorphous said:

In ArchiCAD, the BIM admin can ‘force’ a user out of the file to resolve permission issues. Would be great to have the same in VW.

Vectorworks already has this feature. An admin can release the exclusive lock that User X has on an object/layer using the "Release" command. In VW2019, it has been renamed to "Administrative Release".  Note: I suggest only using this as a last resort, however. Because doing this will prevent User X from being able to commit their work into the PF. 

Share this post


Link to post
  • 0
2 hours ago, Amorphous said:

please also check out this troubleshoot post for other users with PS issues:

This user was using Google File Stream, which is not supported. Project Sharing supports Google Backup & Sync. You can also use Dropbox and Box.

 

If you are looking for a cloud solution, I would recommend Dropbox because of its LAN Sync feature.

Share this post


Link to post
  • 0
On 9/25/2018 at 10:21 AM, Kevin McAllister said:

 

I think this is a big issue for everyone, even those that don't use project sharing. If you're working form a full 3d model, making any small change means many viewports need updating afterwards. Rendering for check sets (maybe multiple times) and then finally rendering for an issue set can take a lot of time.

 

 

I think only Renderworks and the new on demand tessellation features are true multicore. I know geometry calculations are not.

 

Kevin
 

Kevin, you're so right!  Waiting nearly 20 minutes to update a window schedule is absurd.  And a 500MB file should not take 3-4 minutes to save or ro regenerate a section viewport.   

-Carol 

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×