Jump to content
  • 0
ericjhberg

Super slow file opening!

Question

When I conceived this post I wanted to do a comparison of file opening times from VW2018 to VW2019. We have been experiencing dramatic lag in a couple of our files, and I thought it was because of VW2019...however...

 

 when I converted back to VW2018 and ran a test, it took 13 minutes and 32 seconds for the file to open! Proof, watch video...

https://screencast-o-matic.com/watch/cqVbFy3bS8

 

While I am fairly certain VW2019 is still slower, or at least close, I don't really want to take the time to find out and do the comparison

 

This is just one example of where VW needs to dramatically improve. If you don't want to watch a still 13:32 second video of a file opening, what makes you think I do?

Edited by ericjhberg

Share this post


Link to post

13 answers to this question

Recommended Posts

  • 0

Send me that file please. And in the future, I understand things are frustrating for you at the moment, but titling forum posts in this manner makes it pretty difficult to find them when trying to search later or for other users with similar issues. Please name discussions using standard terms and stating specifics.

(The naming certainly hasn't been just you or anything, it's just started to get a little out of hand recently.)

  • Like 1

Share this post


Link to post
  • 0

@Jim Wilson Thanks for chiming in. I understand the directive. I hope that VW sees that perhaps the reason “it’s just started to get a little out of hand recently” is that many users are very frustrated with the current state of things (ie VW2019) and not just a failing social protocol.

 

I will send the file, but it is huge and contains multiple file references, so I’m afraid the one file won’t paint a full picture. 

 

This particular file has been shared with no fewer than 5 VW tech and staff and to date no one can point me to why it is particularly cumbersome. We had it in 2019 but just yesterday saved everything back to 2018 because of a myriad of problems encountered with no solutions offered.

 

I will send you the file later this morning.

 

 

  • Like 2

Share this post


Link to post
  • 0

Would you be able to include the needed references? Without them, the file opened here in 2019 sp2 in 38 seconds.

Share this post


Link to post
  • 0

However upon checking with the techs and file, I have learned the following:
A number of bugs have been filed related to this, but because of the file size they didn't show up linked as normal. So this is "good" news, as it means there wasn't a dropped ball in that area which is where I try to focus on most frequently. The most recent looks to be Detail Viewports not appearing as expected in Best Performance mode, which is almost assuredly a graphical bug.

I have a few questions about this file however, it seems to be a bit far (not exceedingly though)  0,0,0, however none of the layers are georeferenced. Is the 0,0 point just being assumed as the origin relative to a point in one of the referenced files?

I attempted to Purge this file, and was met with the monstrous delay that I believe I saw you describe elsewhere, has a successful purge ever been possible with this file to remove unused resources? Or has it not been purged because of this hang/slowness for some time?

Share this post


Link to post
  • 0
33 minutes ago, Jim Wilson said:

The most recent looks to be Detail Viewports not appearing as expected in Best Performance mode, which is almost assuredly a graphical bug.

This was a different file...different problem in VW2019 than the problems we are experiencing with the 18-005_L-Project file.

 

34 minutes ago, Jim Wilson said:

I have a few questions about this file however, it seems to be a bit far (not exceedingly though)  0,0,0, however none of the layers are georeferenced. Is the 0,0 point just being assumed as the origin relative to a point in one of the referenced files?

Unfortunately we have relied on this methodology to correctly coordinate with consultants who are using the X, Y coordinates (minus the georeferencing) for awhile now. Our problem has been with user origin control and how to manage that across a multiple reference file workflow. In the past we have had problems with origins aligning in different files across the project, essentially moving the project to dramatically different locations. At the time, our best practice was to forget about setting up an independent user origin and just always align it with the internal origin.

 

I have been told repeatedly that working this far away from 0,0 is a problem in VW; however, I have to date, never been offered a best practice or adequate workflow that accounts for the need to correctly georeference files, work with consultants using real world coordinates,

 

This represents one of the largest frustrations I have with VW. The software isn't developed to be compatible with real-world, large project workflows. It is heavily marketed as such, but in application, it poses problem after problem, and often no adequate solutions are provided. It's usually, "broken as designed" or "user error".

 

1 hour ago, Jim Wilson said:

I attempted to Purge this file, and was met with the monstrous delay that I believe I saw you describe elsewhere, has a successful purge ever been possible with this file to remove unused resources? Or has it not been purged because of this hang/slowness for some time?

 

I too was met with delay you speak of. I was never able to purge the file on my system in VW2019. When I converted everything back to VW2018 yesterday, it purged in 2 minutes.

 

I can still send you all of the files, but now I have a conundrum...which version do I send. I have several in VW2019, but re-patching together all of the references will likely take me a half a day. The one I currently am running in VW2018 seems much more stable...still slow, but stable. Additionally, the multiple files represent over 5 gb of data. Where do you want me to upload those?

 

Thanks for your time. I am glad to hear that bugs have been filed and that maybe, just maybe, someday VW2019 might be stable enough to give it another try. Sadly, I don't think it's there yet.

  • Like 1

Share this post


Link to post
  • 0
6 minutes ago, ericjhberg said:

The one I currently am running in VW2018 seems much more stable...still slow, but stable. Additionally, the multiple files represent over 5 gb of data. Where do you want me to upload those?


Send me the whole set in 2018 as you have it currently working please. I'll do the conversion here and test on both and see if I can find out whats going on. However, were techs not able to point out why the file was cumbersome, or did they not mention the origin issue? (Im both checking to make sure we didnt have a misstep in support as well as a software issue.)

The Purge hang happened to me on Windows, but not Mac, so I'll submit that on its own as a purge command bug with the file i already have.

Share this post


Link to post
  • 0
1 minute ago, Jim Wilson said:

However, were techs not able to point out why the file was cumbersome, or did they not mention the origin issue?

 

There have been suggestions as to why there might be problems, including the origin issue, but no conclusions. I reiterate my above concern about origins...if you're asking us to change the way we do things, then please offer a best practice that accounts for all of the intricacies of the coordination issues we face. Don't just tell me that the origin is the problem, fix it.

 

3 minutes ago, Jim Wilson said:

The Purge hang happened to me on Windows

We are working on Windows.

 

Where should I upload the files?

  • Like 1

Share this post


Link to post
  • 0
15 minutes ago, ericjhberg said:

I reiterate my above concern about origins...if you're asking us to change the way we do things, then please offer a best practice that accounts for all of the intricacies of the coordination issues we face. Don't just tell me that the origin is the problem, fix it.


That explains the support issue then. I was worried they just hadn't replied or something, so that's sorted. Tech support reps are mechanics, they can often fix problems, but they dont have the resources to be able to teach users "how to drive". 

In your case, it isn't just simply "This is being done wrong" because you're in a situation that's becoming more and more common, complex interaction between multiple shops with more data-sensitive files then they had before. This kind of thing is definitely what our product specialists are here for and I'm going to try and loop them in to see if they can get (or already have) best practices for this established.

Now, that's of course not ALL you're running into, you're hitting graphical limitations as well because of file complexity, which at the moment has no cure other than "The file must be less complex." which is no good. There is a significant development in the pipeline currently that will do worlds for this, but until I know more details about WHEN we will see it, I'll keep pushing the regular avenues to get a workaround.

  • Love 1

Share this post


Link to post
  • 0
4 minutes ago, Jim Wilson said:

In your case, it isn't just simply "This is being done wrong" because you're in a situation that's becoming more and more common, complex interaction between multiple shops with more data-sensitive files then they had before. This kind of thing is definitely what our product specialists are here for and I'm going to try and loop them in to see if they can get (or already have) best practices for this established.

Now, that's of course not ALL you're running into, you're hitting graphical limitations as well because of file complexity, which at the moment has no cure other than "The file must be less complex." which is no good. There is a significant development in the pipeline currently that will do worlds for this, but until I know more details about WHEN we will see it, I'll keep pushing the regular avenues to get a workaround.

 

THANK YOU JIM! That is the best explanation of our issues I have received in months/years. We feel like we are pushing the software and right now, it feels like it is definitely pushing back. Sometimes it feels like a lonely little island out here in the landscape architecture world of CA, but that is why this forum (and you specifically) are so important. From my interchanges and experiences, we are one of the only landscape architecture firms using VW to do almost everything (we left the rendering capabilities behind a couple of years ago) from conceptual through construction on projects of the scale as the one we have been discussing.

 

My hope for both VW and for us is that the software's capabilities and design start to recognize this need and adjust/expand. There is a huge market there waiting for you if you figure it out.

Share this post


Link to post
  • 0

@Jim Wilson

 

Just an FYI...I am still experiencing repeated crashes in the VW2018 file that I provided you. Sadly I am used to the crashes, and there are too many to report each. Additionally, the 10-15 minute file opening time compounds my day when you have to reopen the file 3-4 times a day. That's almost an hour of lost time per day. If I report each crash and research diligently, that would take up an additional hour each day.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

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.

×
×
  • Create New...