This is Open Source!!!

Performance

• Turning off Event Recording
  

  OmarL records many types of events and stores them in data structures for the duration of a simulation run. These recorded events can be used by the graphical interface to display an event timing chart, which can be of enormous assistance in understanding exactly what's going on in a simulation. Also, recorded events can be used as a logging mechanism, recording data that can be analyzed later.

  However, recording and storing events can take a toll on processing time and memory space, especially in long running simulations. Turning off event recording can lead to a huge performance increase. The variable that controls what events get recorded is: co::events-to-record. The value of this variable is a list symbols which are event types. OmarL will save data about all events with a type equal to one of the types in this list. If you dont care about a certain event type, you can remove it from this list. If you want to turn off all event recording, you can set the list to nil.

  Events are described in more detail in section 9 of the OmarL Programmer's Manual

• Garbage collection
  

  Managing the garbage collector in Lisp can lead to improved performance in many applications. The Allegro Common Lisp documentation provides information on tuning the garbage collector. Here are a few tweaks that have proved useful for OmarL scenarios:

  • Preallocating the heap sizes when creating an image

    By using the :newspace and :oldspace keyword arguments when building a image using excl::generate-application, you can specify how large you want the memory regions to be. If you set them large enough, lisp may not need to allocate more space during a run, and you may be able to turn off global garbage collection. You can figure out good values for these variables by calling (excl::room t) after you run your scenario. This will give you a snapshot of the memory regions and how large they are.

  • Turning off global garbage collection

    When timing data is crucial, you may not want a global gc to occur. You can turn off global gc's with the following:

    (setf (sys::gsgc-switch :next-gc-is-global) nil)
    (setf sys::*global-gc-behavior* :warn)
    

  • Do a global gc at appropriate times

    Right after a scenario has been initialized, data from an old scenario that was running previously should have just been turned into garbage. A good time to force a global gc would be right before the scenario runs. In your scenario code, you could sneak a

    !l(excl::gc t)

    right at the end of your scenario initilization