Showing results for 
Search instead for 
Did you mean: 
Security Alert Log4j Security Vulnerability. Click here to know more.
Showing results for 
Search instead for 
Did you mean: 

ProE delays when working dir is on a network drive


ProE delays when working dir is on a network drive

Hello all,

we are facing the following strange behavior.

We are running 3 licenses of ProE (WF 4 M140) without intralink or any other PDM system. We are storing our models on a network file server and the users work exclusively there.

What we have noticed is that the performance of ProE (eg regeneration time) depends on the number of files that the working directory holds. The more files on the working directory, the more time the regeneration needs!!!

Am I missing something here?

Thanks in advance.

Vassilis Anagnostopoulos

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

We have noticed that, when running Pro/E from a network drive, there can be a delay in opening a menu when you haven't used that menu for some time. Once the menu is loaded, it seems to be cached and then loads instantly.

We hadn't noticed the regeneration time issue; we've just tested it and couldn't measure any difference (~18sec regen time, 1016 files vs 124). We haven't tested moving the .prt file to different directories, though.

Where are your trail.txt files being written? Your system may run faster if you write them to a local hard disk; if you're writing them to the (network) working directory then perhaps that has an effect.

... yes, our trail files are stored locally to c:\temp.

I will explain you, how my test procedure is, just in case you want to give it a try.

1. Set a working directory locally, say to c:\temp

2. Create a simple part with two features, one protrusion and one cut.

3. Suppress the cut feature

4. Resume the cut feature and measure the time the model needs to regenerate and update the geometry (it should be almost instantly).

5. Keep the part model in memory, don't erase it.

6. Set a working directory somewhere in the network. This network folder must have as many ProE files as possible. (in my case they are about 5000)

7. Suppress the cut feature

8. Resume the cut feature and measure the time the model needs to regenerate and update the geometry (in my case this is about 4 seconds!).

I would be really thankful, if you can make a short test like this and inform me about your findings.

Thanks a lot for you time and effort.

Hi Vassilis,

I've just done the test exactly as you describe.

In both cases the regen time was too short to measure. The biggest working directory I could find was the one with 1016 files, though.

WF4.0 M110 on XP32 Pro 2002 SP3, by the way.

All the best,


Hello Jonathan,

thanks for your info.

What kind of files do you have on your big directory? Are, they ProE files? Because if they aren't ProE files, then they don't affect the regeneration time.



Hi Vassilis,

934 of those files are .prt, .drw or .asm. (It is primarily a directory used for Pro/E files.)

Hello Vassilis,

any answers to your question from PTC Customer Support or somebody else?

seems that one of my customer is experiencing exact the same problem. With Creo 2 M110 and M140.

Since this question is quite old (I found it by using the search function...) - anyone got some new ideas on that ???

Especially the regeneration of an assembly (in session) seems to depend on the number of Creo files *.prt and *.asm which are in the working directory.

Thanks for any tips on this.


I just had a three to four month go around with an outside IT firm and my reseller. They basically told me I had to many files in my folders and that is what is bogging down the computer. (Two systems over a network). I was told the only solution was to break down my files into separate folder, but they couldn't give me a threshold below which would be optimal or even significant increase in speed.

Thanks, Dale

22-Sapphire III

While I have seen that the maximum number of files in a disk/folder is 4G and the maximum size is 256TB, I don't think you are seeing those extremes.

For efficiency of the OS searching folders to find a file, I have heard that 64K files is a practical maximum. I have PDMLink set to roll over to a new folder when we get 50K files in a folder. I am currently writing to folder 45. If I was not using a PDM system, I would limit my folders to 20K files to make it easier to search through the listing.

22-Sapphire I

Currently I have ~19k files in the primary folder (some have been moved to secondary folders). Accorder to the folders properties, there is 6.4 Gb of data within the folder and its 23 subfolders.


This is odd, and I guess my answer is ..uh..suitably odd.

Back in the days we experienced similar problems with Proe2001 / Win XP when working with Intralink via a Novell based network. Suppressing a feature in a simple part took about 30 seconds on a mid-range machine. Even after a fresh start you could find files in your object list (Files - Manage Session - Object list) with no relation whatsoever.

This did the job: Changing the setting "browser_favorite" to the same path as the working folder (might want to work with a variable in your start script there) and deleting all other paths that were linked as favorites since all the objects there to be found were loaded and monitored by the system.