Straight from the PTC website. If you have XP you may be able to use their suggested technique to increase the process memory
Pro/ENGINEER exits when running out of memory on a Windows workstation prior to reaching the 2 GB memory limit for 32 Bit applications.
Currently Pro/ENGINEER running on Windows workstations is a 32-bit process running on a 32-bit Operating system. The operating system and the compiler used to create the executable cause Pro/ENGINEER to be constrained by the 32-bit limitation.
With respect to Pro/ENGINEER, the 32-bit limitation refers to the amount of memory that can physically be allocated for a SINGLE process. Memory is allocated to memory addresses, which in the computing world are represented in binary format (one's and zero's). For example, the following two lines could each represent one memory address:
0000 0000 0000 0000 0000 0000 0000 0001 a(31 zero's and one 1)
Each combination of ones and zeros represents a different memory address or pointer. There are approximately 4 Billion combinations or approximately 4 Gigabytes of memory addresses. This value comes from the number of options for each bit and the number of bits available or 2^32 = 4.3 Billion. The 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage.
This limitation is independent of whether the memory is Swap or Ram.
Due to memory overhead the actual amount of memory that a single 32-bit application running on a 32-bit operating system can access is generally closer to 1.5GB. In general this limitation is a hard limitation on 32-bit platforms. However, for Windows XP Professional (32-bit) there is a PTC-supported Microsoft procedure for enabling larger process memory addressing. For information how to set this up, please refer to TPI 113330 located at:
What operating system ae you running? Have you checked the amount of swap space or virtual memory set. If this has not been cheked since installing the pc, it may be set too low. It should be set at 1024MB (per drive) minimum. I would also check your anti virus. We use Mcaffe on access scan, which can affect proe. When working on larger assemblies, i have to turn the antivirus off.
PTC doesn't tell you everything in the Tpi. We tried the 3GB switch. Which is actually 2.6GB. We were able to retrieve the model at 2.4GB that is until we add more items to it this week.
Rendering was very slow and performance was unacceptable. You really can't do much with the assembly. Adding components and regen time were real bad. We also had windows service packs conflicts. We were told not to run certain service packs. We are network based and by not running these service pack it leaves our network vulnerable.
This was given to me by our network admin!
Here is the link on SQL server, a 32 bit application.
It can use as much as 64 gigs of memory on a 32 bit platform, what is the difference? PTC is unwilling to review this new data. If microsoft can do it why can't they.
Unfortunately I do not have a solution, just a way of opening up the assembly without having to call up all components into memory. When opening an assembly, choose Simplified Rep and create one if you do not have any created. Simplified Rep is an option in 2001 at the bottom of the screen when you are opening a file and an assembly is chosen. I do not know about Wildfire? By creating a simplified rep, Pro/E only calls up the components comprising the simplified rep. The setback is at some point in time you will have to call up all components of the assembly (Master Rep). And, for that issue, I don't have a solution.
Upgrading to XP would probably help the memory issue some.
If the operating system is Windows 2000 Advanced Server, SQL Server 2000 Enterprise Edition can use up to 8GB of RAM. If the operating system is Windows 2000 Datacenter Server, SQL Server 2000 Enterprise can use up to 64GB of RAM.
I doubt any PTC customers could afford to put either of these applications on the desktop. This is purely an application server environment that allows such memory usage. Therefore, there's not an incentive for any desktop application manufacturer to write code that way.