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.