Improving ObjecTime performance

Toolset

All Versions

Some suggestions/tips for improving ObjecTime performance:

1. There is an option at the end of the list of merge options called cancelleable.
    
   Cancellable provides a safe merging mechanism. If there is a failure during the merge (e.g., tool, power, etc.) you can revert to the pre-merge state. To speed up merging you can deselect cancellable, however recovery in the event of a failure becomes your responsibility. If the merge fails (i.e., power fails, you run out of disk space, an objectime exception is raised, etc.) then you may need to abandon the image and restart the tool. If you are starting with passivated updates (i.e., a known state), then this might be an option for you.
    
   A non-cancellable merge must keep track of all changes so that they can be undone making it a very memory intensive operation. It is possible that RAM requirements for the merge can be twice the updates normal requirements. If you must have other applications running, closing them down during a merge, to free up RAM, will help. (see note 3)
    
2. To optimize the size of the update a procedure is:
    
   
   1. Passivate your updates and contexts.
   2. Make a new context from the update you are optimizing
   3. Remove the update
   4. Passivate the context
   5. Remove all user contexts and updates
      At this point you should have a clean image.
   6. Activate the context
   7. Make an update off of the context
   8. Passivate the update, and remove the context
   
   If the update's size was reduceable, this procedure should do it.
    
3. Make sure there is enough RAM available to avoid paging. A passivated update can more than double in size when it is loaded. Are there other applications running? On some systems even clocks and shell windows require a 1Meg of RAM each. Assuming that the update size cannot be reduced, a 30Meg update will require 60Meg+ of RAM. Add to that, the toolset requirements, NFS, shells, etc., and it is possible you still have a shortage of RAM. If there is not enough memory to keep the tool in memory, then ensuring that the tool is not paging by increasing RAM would also help.
    
4. Avoid acccess across the network. Activate and passivate to a local disk and then copy (cp) the file. Make sure swap is also to a local disk.
    
5. Parallel make can improve compile times.
    
6. For your simulation performance issues. When performing mixed mode simulation the toolset must communicate with the simulation C++ process. Actors in the C++ process may have to communicate with RPL Actors. The communication between the two models is less efficient than between RPL Actors, or C++ Actors. Try to minimize the interaction between the two models.
    
7. To speed up initialization. Do as little as possible at at actor creation time. Provide an interface to explicitly initialize/start each actor. Some advantages to this are:
    
   
   1. faster start up
   2. only need to initialize actors which are part of test
   3. not dependent on start up order (no race conditions)
   4. explicit control over actor start/restart/stop/shutdown.

See also: Resource Usage troubleshooting guide