The issue we're having is with repeated patterns you're using on a general reference mode pattern. With one of these patterns (repeated use of an objectName general reference mode in 1-1 object types) I'm not surprised you're having problems. The other one similar pattern (description) I expected to clear up when I deleted the (apparently old, there is no shape for it) ElementTypeHasDescription FactType, but it didn't. In any case, you can get back to normal performance if you use popular reference modes instead of general with these two repeated patterns. Basically, you end up with a chain of about 30 1-1 FactTypes (note this includes the reference mode FactTypes that are collapsed by default) involving the objectName value (and even more for description), and the hangup is trying to figure out the most efficient direction to map the 1-1 relationships. Obviously, we need to take a serious look at the range of choices we attempt to optimize here.
To make the model more performant. I'll mark things that will change over time in [:
(To save time later) Go to the 'ORM Designer' page on the Tools/Options dialog.
Change 'Initial Data Type' to 'TextVariableLength' [We'll eventually add facet options (length/size/precision) here as well, the lack adds a step later]
Change 'Final Shape Deletion' to 'DeleteShapeOnly'
(optionally) Change 'Delete Key Behavior' to 'DeleteElement' (this makes the Delete key delete an element, and Ctrl-Delete delete a shape)
(optionally, tangent) You have a lot of definitions in place, so you might want to turn on 'Show Definition Tooltips'
Back in the model, delete the 'ElementTypeHasdescription' FactType using the ORM Model Browser
Add a new diagram (temporary, we'll delete it later)
Open the 'ORM Reference Mode Editor' tool window
Expand the 'Custom Reference Modes' branch and click on <add new>
Enter objectName (be sure to match the case) and then change the Kind to Popular. [You'll eventually be able to set an intial data type here as well.]
[The appearance of these shapes is a bug, but we'll leverage it to change the DataTypeLength]. There will be a big blob of shapes in the diagram.
Activate the diagram
Ctrl-A to Select All
Choose 'Auto Layout' on the context menu to get a stack of shapes.
Start a lasso select to the right of the left edge of the ValueType shapes and make sure you pick up all of the FactType shapes. Delete the shapes (make sure you don't delete the elements, the keystrokes depends on your key mappings).
Ctrl-A to get all of the ValueTypes and change the DataTypeLength to 50
Delete the ValueType shapes
Repeat steps 5-7 for description instead of objectName, setting DataTypeLength to 250 instead of 50
Delete the temporary diagram
Your model will now perform as you expect. You can see the remapping speed by expanding the 'Relational Schema/Schema/Tables', making a significant FactType change (expand a single role internal uniqueness to a spanning uniqueness, for example), and watching how long it takes for the Tables node to collapse. [This is test will not long-term because we won't be fully regenerating].
Basically, the issue here is that every time you added a new use of objectName or description as general reference mode patterns, the possibly mapping combinations increased exponentially, and the performance went the other direction. From a modeling perspective, by using a general reference mode pattern instead of a popular pattern, you've effectively stated that you want the objectName to be unique across most of your EntityTypes, which I don't think is what you were after. However, the pattern you used should not run the machine out of memory.
If you don't mind, I'll isolate the issue with a smaller file and keep the original (locally, not as a submitted test scenario) as a performance check.