Memory Management Tips

I have a few memory management tips that I thought I would share.   If you have other debugging tips then please share them with us.

The Memory Usage Block in the Utility Library 

The Memory Usage block will show you the amount of memory each block, each h-block, and each database table are using.  This list can be sorted (by clicking at the top of the column) to show you which ones are consuming the most.  It is the first step to making your model more manageable.

History Blocks

If a History block shows up in the Memory Usage list as a major consumer of memory, check out how many rows are in the history table.  From time to time, I will set a History block up to record more than just 1000 rows (default).   I might want to set it up for 10,000 rows or more, so I can see all items that traveled through it.  If I ever forget to reset this back down to 1000 rows or even delete the History block altogether, it can consume a bit of memory with an excessive row quantity.  I also like to set up the History block so the data is not saved when the model is saved.  Finally, I like to use the temporary History block if I am debugging.  This is the one that dangles off of an item output.  I like to use this one because every so often I can delete them all with a simple right click.

Queue Item Contents and Activity Item Contents

If an Activity or Queue shows up in the Memory block list, check out the Item Contents tab. The Item Contents tab on the Queue and History can get large under various conditions. For example, if you are showing the historical log and have many items have traveled through it across the run, then it does take up a great deal of memory. 

Database Tables \ Log Tables

If a database table shows up in the Memory block list, check out how many records the table contains.  Tables that contain a log of items or events that constantly grow can be pesky at times when it comes to consuming memory.  The log tables are useful for debugging and analysis; however, when doing really long runs for multiple replications, they can become huge.  I suggest you add a flag as a user input that has the capability to turn off capturing the detailed log table in situations where the table isn’t necessary. The flag is useful when you are performing a large number of replications for a study, and you are really only interested in the high-level results and not a detailed log.

.BAK file

By default, the model makes a backup copy of itself every time you save the model.  This file has the same name but has an extension of .bak instead of .mox.  The model will use this when you use the function File \ Revert Model to revert the model to the last save version.  The backup file isn’t necessary for any other reason.  For older versions of the model, you can definitely delete their .bak.  If you don’t want to create the .bak file in the first place, there is an option that you can set to turn it off.  This can be set in the Edit\Options\Misc tab.  By the way, when you email your model to others or you make a backup copy of the model, the .BAK file does not need to be included.