[ORD 2021 R2] Is OpenRoads really this slow?

Hi Chuck,

caddcop said:

We are currently working with Bentley on a complete revision to our Workspace

it would be great to share a summary or "best practices learned" from such project. I do not recall any such document available (but ORD is not the main product I work with), but I often use workspaces with long history, where probably plenty of things are obsolete or can be done better.

Regards,

  Jan

Hi Mary,

MaryB said:

I am not using ProjectWise.

Although usually PW is treated as a reason of slowness, maybe in terms of managing workspace it would help.

MaryB said:

I am working over a VPN, which is, admittedly, slower than hardwiring to the network at the office.

Yes, network is slower than local access, VPN is slower than normal network.

I would guess that it can be the biggest reason, why ORD is slow. The workspace probably contains hundreds (or even over a thousand) files, but the most important are dgnlibs. How many are there? And the dgnlibs contains thousands of definitions, that all must be read.

I recommend to try to copy the workspace to local disk and to compare the difference.

MaryB said:

but I wish there were a way that certain DGNLIB files could be loaded more on an "as needed" basis.

In my opinion civil team has tried to optimize how dgnlibs are loaded (like to filter dgnlib by its name, not only by variables), a question is whether existing workspace(s) are structured to be able to use these optimizations. "Ad hoc" loading sounds like good idea, and it is up to developer when data is queried and loaded from dgnlibs, but the problem of ORD is feature definitions complexity: To load complete feature definition requires to load "everything" ... levels, templates, annotations etc. On the other hand, to open and display file, no these definitions are required, because when used, the definition is copied to local file.

MaryB said:

I had seen threads for years that ORD ran slower in general than V8i.

Yes, it's correct. And although every release brings some optimization, it's still quite slow product.

MaryB said:

I guess I didn't really think much of it.

In my opinion the speed and time you mentioned are not normal, especially when talking about file opening. I can imagine, when there are hundreds of sections and something is changed in alignment, to update complete chain (corridor, annotations...) can take a huge amount of time.

With regards,

  Jan

Our first effort at an ORD workspace tried to preserve a number of legacy settings so that migration of project files might be seamless. This proved to be a fool's errand. Apparently the CONNECT platform introduced some fixed or standard resolution units that must be used that were different than our legacy workspace. This impacts cells, linestyles and more. Also, we had many legacy files that had a shifted global origin. We had addressed this for most obvious files - seed files and any standard drawings. But had not looked into our many cell libraries. Within these, we a mixture of shifted and non-shifted GO's. The other major issue was how we used the Scales.def, Sheetsizes.def and Units.def. We built the 1" = 1' plotting scale into those files so our 50 scale was 1:50 and not 1:600. This setting from V8i was not supported in CONNECT.

Our contract with Bentley now contains credits for getting help for customizing the various products (primarily Workspace files). They develop documents called Blueprints that outline the processes and deliverables and specify how many credits these will require to accomplish. We had them develop two blueprints to analyze and report on our ORD and ORD DU workspace files. After those were completed, we had them develop two blueprints to make the changes recommended by those reports. These documents are for our internal use only or for use by consultants we use to assist us in managing our workspace.

A major part of these tasks was to revisit our Feature Definitions, Feature Symbologies and Element Templates. Many of these were migrated from InRoads. But InRoads Features and their Symbologies to not align with Open Roads. This resulted in a lot of settings in these being defined in areas that were not needed and, in some cases, missing or mislocated from where they were needed. As part of fixing these, I looked at some other agency files. What I ended up with was a root organization in my Element Templates that had an Annotation folder, a Linear, Point, Profile, Surface and Solid Folder plus a folder for non Open Roads items that will eventually be hooked up to some ribbon menus. Then, under those folders, the structure is very similar to the Symbologies folders which also mostly replicate the subfolders of the various Features subfolders. The benefit of this is there was a natural segregation of different settings according to the appropriate parent folders. and it makes searching for settings in each location a similar effort.

Once we finish the workspace, it will be published for all to see and each an decide if they think our approach seems appropriate. 

I believe that you are right that a lot of this slowness is a combination of complexity and my VPN, although software slowness is certainly a factor, too.

I am certain the client workspace isn't exactly optimized either. It seems as if all DGNLIB files are loaded every time I change files. I would have thought that files would be loaded on the first drawing of the workset, and I guess I didn't think they would need to be loaded between files. I can grasp the concept (file close/file open) but it seems very inefficient

I would be interested in seeing the "best practices" for optimization as well. Since this client isn't likely to update often, it may be worth creating an optimized configuration (if that's all it is - configuration variables).

I know my organization has the workspaces stored on a central server location and pushed onto our local drives at a certain time interval. Not an technical guy at all but from conversations with IT, they seem to think it helps a lot.