I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff,

I tested this theory with one of our DOT workspaces and I did see a significant speed difference in ORD on Projectwise.  I went extreme on my testing and put all the resources in one dgnlib.  The only exception was a separate dgnlib for civil cells and a separate dgnlib for drawing seeds. ORD is always pulling resources from dgnlibs , even certain commands will trigger a scan of resources. (place dimension)  This is opposite of v8 when resources were loaded at the beginning of the session and that was it.

This theory is worth looking at.  I think some resources in multiple dgnlibs conflict with each other at times.

Also to increase speed try adding a custom variable defining the dgnlib resource folders and get rid of the wildcards used in dgnlib variables.  (*) .  Typing out the full file names seems to load files a little quicker in Projectwise.  Projectwise isn't wasting time searching and scanning folders for files.  The files are already downloaded before the dgnlib variables are even set. 

This is My Two Cents

Thanks, Zane.  San Diego is PW-based, so your recommendations have direct relevance.  So, what triggered your test?  Is there a recommendation from Bentley out there?  I'd sure like to get actual Best Practice Recommendations (and supporting data) from the vendor.  They have a unique ability to see patterns and enough data to provide quantitative recommendations - if they were determined to do so.  We'd all benefit.  In the meantime, I am grateful to you and the other contributors to the forum, who help us out even though it is not their job to do so.

Zane:

Thanks so much for your work here; much appreciated!

I do wonder if "also to increase speed try adding a custom variable defining the dgnlib resource folders and get rid of the wildcards used in dgnlib variables.  (*) .  Typing out the full file names seems to load files a little quicker in Projectwise" would work for a standard Work Station installation... certainly worth a shot and wouldn't take much time to accomplish. I will try and carve out some time and test this- your- idea and get back with y'all on it!

Mark

thank you, Mark.  I look forward to your results.

We are advising all our clients to skip the mega use of wildcards for loading libraries and instead explicitly define every file needed in the CFG file.  This has two benefits:

1. It is noticeably faster to load the workspace and open files.
2. Following the Bentley pattern of CFG files results in ridiculously long file names which are offensive, plus if workspace is on a network drive, you can still get into trouble when the path plus filename exceeds 256 characters. 

We are advising all our clients to skip the mega use of wildcards for loading libraries and instead explicitly define every file needed in the CFG file.  This has two benefits:

1. It is noticeably faster to load the workspace and open files.
2. Following the Bentley pattern of CFG files results in ridiculously long file names which are offensive, plus if workspace is on a network drive, you can still get into trouble when the path plus filename exceeds 256 characters. 

Robert,

Great Reply,  Character length still does still matter!  Also special characters matter.  I have seen ORD issues with use of special characters in feature definitions, file names and even folders on Projectwise.  i.e. we had files in Projectwise that weren't printing correctly.  The folder had special characters so we renamed the folder and the problem was solved.  

ILikeTheFactThatTheFileNameTellsWhatsInTheFileButYeahThereAreCharacterAndDecencyLImits.dgnlib

:-)

I am suggesting your most recent post, Jeff, as an answer to our issue.

Mark

Excellent, Robert!

Mark