[ORD 2021 R2] Is OpenRoads really this slow?

Hi Mary,

MaryB said:

or is ORD very slow compared to Inroads/Geopak?

I have not too much experience with InRoads, but yes, OpenRoads is often slower than InRoads. Similarly to MicroStation: Often CE is slower than V8i, on the other hand sometimes faster, and what is more important (at least for me ;-), is able to handle data and finish tasks, when V8i crashes or is extremely slow.

MaryB said:

it takes 5+ minutes to open the first design file.

It sounds like too much. It's not clear how you start ORD (in ProjectWise, opening a file directly without file selection in a middle of start...), but my ORD 2021 R2 offers to select file about 15 secs after start. And the file opening depends on the file complexity and workspace complexity (but still typically under a minute).

MaryB said:

Every DGNLIB from my client workspace has to load, and with all of the settings, there are a lot of DGNLIB files.

Yes, it makes sense in my opinion: ORD must load all settings to be able to work with DGN file.

To keep workspace as small and simple as possible is one from important requirements to keep any OpenX product "fast". To have hundreds of files (especially dgnlibs) with thousands of levels and other date, belonging to feature definition, when only a fraction is used, makes loading process slower than necessary.

MaryB said:

I am using a client workspace, so this isn't anything I set up myself. Are there any settings I should look into, or any way to speed it up?

When it's not your workspace, so I guess you cannot modify it, there is probably not too much what can be done. As Mark asked, you do not share all details (ProjectWise is used, how complex the files are, is workspace local or on server...), but you should ensure all files ORD uses (workspace) are local, so there is no delay when located and read.

MaryB said:

Windows 11, 32 Gb RAM, if that makes any difference.

My experience is that more than RAM (Bentley products are usually not able to effectively use all available memory, so anything above 16GB is probably fine), fast disk can help. Today it means NMVe SSD (and not old SATA or a mixture of M.2 form, but still SATA internally).

With regards,

  Jan

I am not using ProjectWise. I am working over a VPN, which is, admittedly, slower than hardwiring to the network at the office.
The files are not complex. I have this delay even when creating/opening new, empty files to begin working.

I always open ORD from the desktop icon. After so many years before workset branding, I may never trust that just double clicking from Explorer would open the proper workspace...I am old.

We do not store workspace files locally because the work of keeping every machine updated with the proper copies of every client workspace for everyone who uses ORD is simply impractical. It is also MUCH easier to administrate those workspaces, with associated worksets, etc. from a central location on a server than to try to keep track of everyone's computer. Our IT department are generalists, without much CAD or CAD Admin experience (as far as I can tell).

I think some of it is an overabundance of client resources, and the fact that they all need to be loaded every time. I understand why that is, but I wish there were a way that certain DGNLIB files could be loaded more on an "as needed" basis. I am not going to need my sheet creation DGNLIBs for weeks, yet there they are, all two dozen of them, every time I open OpenRoads. File switching is much faster than initial opening, for which I am grateful.

I had seen threads for years that ORD ran slower in general than V8i. I guess I didn't really think much of it.

We are currently working with Bentley on a complete revision to our Workspace and there are a number of things that can be done with DGNLIB's that apparently speed up load times, but it requires recreating a number of DGNLIB's. It's possible your client's workspace is still using the older methodology. All you can do is hope that they will update the workspace to incorporate these changes.

Considering that this is their very first, freshly released ORD workspace, my hopes are not high...It look as if they have done good work to get what they have, but it's taken this long to get here so I don't expect updates any time soon.

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. 

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.