Pro/E is very slow to open assemblies thru the network

Here is the case:

Large assembly (more than 5000 components).

Many component and libraries have family tables.

All files for the project and libraries are on the Dell Network Server, nothing is local.

The Network has a high speed switch and NIC's are Fast Ethernet 100Mbps.

Dell Precision 420 workstations work on this project.

Many, many search_path and they are all valid. Have checked them all (not that I like to have many search_path, but that is the way it's now)

Trail file is written locally to each workstation.

Pro/E takes about 55 minutes to open the assembly and CPU usage is only 2-3 percent.

Here is part of my troubleshooting:

I ran a Pro backup of this large assembly to a local folder on a workstation.

Created a new without the search_path and Now everything is local.

Pro/E took 3 minutes to open the complete 5000-part assembly and CPU was

at 90 to 100 % while opening the assembly.

If I move a large number of files thru the Network it runs fast. This tells me that Pro/E is causing the slowness.

I connected a network cable from one workstation directly to the Server (to by-pass the Switch) that has all the files and still Pro/E is slow.

The mystery is why Pro/E is slow thru the Network and fast locally.

Why the CPU of the workstation runs at 2-3 % while retrieving the assembly thru the Network?

Summary of Responses:

Check to see if you have a drive mapped on that machine that is no longer active.

Add to your             NT_CACHE_DIRS    YES

Addresses performance issues that occur when Pro/ENGINEER is used with NTFS-mounted file systems. Customers may experience degraded performance upon selecting Search/Retrieve when displaying large NTFS network directories, and/or excessive retrieval times when attempting to access models on an NTFS network drive containing a large number of files. This option affects NT-mapped drive configurations only, not NFS-mounted file systems.

Refer to the on-line PTC Technical Support TAN Database for more details

    ``yes''--activates option                        ``no''--deactivates option

ProE will look for files in the order you wrote your search path. You can make the following test:

Make a backup of your assembly to a directory in your server

Add this directory to the start of your SEARCH PATH

Open your assembly and test the difference in speed.

If you see a big difference in the previous test you could try to change the order of the directories in your search path. ProE will retrieve objects faster if it can find the objects at the beginning of its search path. You could even make a mapkey which would load a new search path which works better for your


Another important point is how you deal with family tables. When ProE needs an instance, it will look for it inside the .idx file in the directory it is searching. If it does not find the instance, there is an option which, when set, makes ProE to look inside EVERY model, to see if that model is a family table, and the instance is there. Then, it will search the next directory. I imagine this option is useful if your .idx files is not useful, but it can take a long time to look inside every object. This option,

INSTANCE_SEARCH_EXHAUSTIVE should be always be set NO, and the .idx files should be kept right.

How many hops does the circuit make.  Just because you are running at 100 does not mean the full circuit is.  I have had this problem after IT decide to add hubs and hops.  IT does not understand that Pro/E needs its own network.

The problems you are running into could be that if you are running under windows NT4.0 that there is a registry setting missing in the registry of the server and the clients.

Follow the example below, add the registry parameter to the server and all clients. YOU WILL GET A PERFORMANCE BLAST UP TO 300%

Go to start and select run

type regedt32

(You will end up in the registry)



Create the following registry entry on this place

Create the SizReqBuf value with the following information

Value Name: SizReqBuf

Data type: REG_DWORD

Data: 5120  (decimal)  this is the value you should use for pro/e


Just one thought;  when you have search paths, ProE searches each folder 100% until it finds the first occurrence of the part.  If all of your parts are in the last folder searched, the time is at its maximum.  When all files are in the first folder searched, the time is minimum

Try putting all files on one folder on the network, editing the to only that one search path, and see if the time improves.  It's been years since I used search paths so (hopefully) performance has improved and I am wrong -- but I doubt it. 


NT_CACHE_DIRS yes (you should have turned this on a long time ago)

USE_TEMP_DIR_FOR_INST yes (this is sometimes overlooked, default is retrieval directory)

SAVE_INSTANCE_ACCELERATOR always (get admin permission, disk space will skyrocket)


The problem is most likely in the large number of search paths.  Take that single directory of files from the Pro backup and place it on your server.  Try loading your assembly without any search paths. (like you did on the local machine)


It's the number of search paths and the fact that those directories are on another machine. Also, if your working directory is network mounted, you will be much slower than if it is local.


I suspect your problem is trying to use your network to send to much data



100Mbps is good.

Switch is good - should allow full duplexing on network cards.  This will double the rate of data transfer across the network - provided the NIC's can handle.

NT vs. Unix

I wonder if there are different server routes for network data packets of info.  NT can run really slow if it's looking for a machine that it can't find or is difficult to find (across gateways/bridges/routers).  It could be that a totally unrelated NT process is slowing down your Dell Precision 420's access to ProE data that doesn't affect the Unix systems.  In my experience, this problem has been difficult to find because someone else set up the part of the network that is causing a problem.


It seems like UNIX boxes are always faster at networking. Are you running some kind of NFS server on the NT server for the SGI's?

Are there any NT boxes that are fast on the network? Although you said other files are fast, maybe it's time to look at protocols and bindings. NETBEUI is plenty fast, but doesn't route. It's also very chatty, but it's the best choice for small networks. TCP/IP is straight forward, but needs to be set up right.

Since your UNIX stuff works right, I'm going to assume TCP/IP is running well because it's been around longer. I'd start looking at DNS/WINS, routing, and network protocols/bindings.


If you have a lot of mapped drives, disconnect anything that you can temporarily and see if that helps.  If it does then you can maybe weed out a mapped drive that is causing problems. 

Unresolved network problems will slow Pro to a crawl on NT machines.

Also check your page file settings.  This won't help your network problem, but it will help the overall speed of the machine.  I hunted multiple sources to find exactly what the page file should be set at and here is the answer I go that worked in the end.  Up to 500MB page file (swap) should be twice the amount of RAM.  500MB and about, the page file should equal the amount of RAM.  HERE IS THE IMPORTANT PART.  The upper and lower limit should be the same.  That sounds a little goofy, but the way that NT operates, the lower you set the lower limit, the earlier it starts to swap.  That makes absolutely no intuitive sense, but it works.

Another thing about swap is that you can't defrag it.  Over time you will end up with fragmented swap all over your hard drive.  There is a way to clean it up, but it is very tedious and it doesn't work as well as I would like it to work.  The best way to set up swap is set up a separate partition on the drive just for swap.  This can be a little painful because it means reformatting the hard drive.  But that is the only way I found to keep an NT machine running smoothly without rebuilding it every 6 months.

Another thing to consider, are you running Office 97?  I loaded Office 97 on 5 NT Alpha machines and the speed dropped by half.  These were Alpha machines, so I don't know if Intel machines have the same problem.

In retrospect, we also had some network problems that were probably causing the machine to slow.  But the fact still remains that when I put Office 97 on a machine that we had only had a few months the speed dropped in half.  When I rebuilt the machine and put Office 95 back on it, the speed came back.  Simply uninstalling it didn't do the trick.  My theory is that Office 97 (and probably 2000) makes a lot of

network ties.  Uninstalling them didn't clean that up.  On thing that Office 97 was messing with Pro is that the font of ProE changed when we loaded Office 97.  It didn't change back until we rebuilt the machine.

Don't know if that will help, but that is my 2 cents... well maybe a buck fifty.


Check in the control panel, network, protocol.  Is the NetBEUI and TCP/IP  protocol shown?  Then check bindings.  NetBEUI protocol should be first with  WINS Client(TCP/IP) second under the NetBIOS interface, Server, and  Workstation.  I had the same problem with SLOW  retrieval of  assemblies on another work station that went through a server to get the  components off an external hard drive located on my computer.  All are IBM M  Pro machines, NT, 2000i.  Hope this helps.


I apologize for not knowing the source, but I do recall this being asked before.    A registry hack is available from Microsoft Product Support Services article Q177266:

"SYMPTOMS:  When you list the contents of a remote folder to which your computer is connected by TCP/IP, the results may take much more time to display than when you view a local folder."

This is also from the MS Product Support Services  article Q177266: 

"According to RFC1122, TCP uses delayed acknowledgments (acks) to reduce the number of packets sent on the media."   

The delay is built into TCP.  You may need to do registry hacks to improve the file access across the network.


We had the same problem with large assemblies. We made a change to the registry and the problem was gone.