See this paper for an overview of techniques which can improve model speed substantially.

An important first step in figuring out how to optimize your model is to estimate how much memory your model should consume. For the purposes of this page, let's assume that we're working in NetLogo 2D, version 5.3 (NetLogo 3D would give different, larger numbers). A standard Turtle in NetLogo takes 121 bytes of memory, and holds on to ("retains" in JVM parlance) another 316 bytes for a total "retained size" of 437 bytes. Similarly, we can obtain these numbers for each agent type:

Plus for each agent variable, we add 8 bytes to the retained size. Note that 8 bytes is a minimum. If long strings or lists are stored in an agent variable, that number will grow considerably. So we can use these numbers to obtain the expected amount of memory for a given type of agent using the following formula:

agent-memory = (<empty-agent-size> + (8 * <number-of-agent-variables>)) * <total-count-of-agents> 

Once we've calculated the formula for each agent type, we can obtain the expected amount of memory for the model. On top of that number, we add another 16 MB, as that's the memory size of NetLogo with no agents. So the total formula is:

total-model-memory = sum of agent-memory for each agent-type + 16 MB

Once we've figured out the expected amount of memory, we have two ways of trying to get the model running better. The first is to shrink the amount of memory used by the model (see "Tuning the NetLogo Model"), the second is to tune the JVM to make the model run more quickly (see "Tuning the JVM").

Tuning the NetLogo model is largely about removing unused agents and variables. You can audit your NetLogo code and see whether any of the agent variables are unused and can be removed. Remember that for every turtle variable you remove you can see a savings of 8 bytes of RAM per agent.

If your turtles don't interact with patches, you can resize the world to be a single patch, which can save a small amount of memory for a standard-sized world, but quite a lot of memory for worlds that have gotten large (but don't need to stay large). Patches are not automatically disposed by NetLogo if not used, so removing as many as possible can be helpful in lowering NetLogo's footprint.

Although it will not reduce the amount of memory your model uses, you may find that changing strings passed to run and runresult to tasks will increase the performance of your model.

Additionally, if you are running NetLogo using an outside tool (such as R or Mathematica) you may find you can substantially reduce total memory usage on your computer by running NetLogo directly. Depending on your needs, it is probably possible to get data about your model for later analysis in these tools using BehaviorSpace or export-world to write the relevant data to a CSV file.

Tuning the JVM is a bit more difficult and will require some experimentation to be effective. To start with, use NetLogo 5.3 as it comes bundled with the Java 8 JVM, which is much better at managing memory than the Java 6 JVM with which prior versions were distributed. You will also want to use the 64-bit version of NetLogo if running on Windows as 32-bit applications cannot make use of all available RAM if you have more than 4GB installed.

The first step in JVM-tuning is usually to increase the amount of memory available to NetLogo; the process for doing this is described in the FAQ. This section also describes the location of the configuration file, as well as where java flags are located within the file.

Using the amount of memory calculated in "NetLogo Memory Usage", you can provide the JVM option -Xms<amount of memory> to help speed up your model by telling Java to preallocate as much heap space as you will need. This flag looks like -Xms2048m or -Xms2g (use the suffix appropriate to the size of memory needed).

If agents in your model appear and die throughout the lifetime of the model, it may be beneficial to consider changing the JVM's garbage-collection algorithm using JVM Options. The Oracle documentation provides guidance about GC tuning.

Some NetLogo users have access to high-performance machines and would like to optimize NetLogo for speed when running headlessly. Here are some ideas:

Increasing the NetLogo memory usage in netlogo-headless.sh (or a custom shell / batch script if you've written your own) is a fast way to increase the performance of models with many agents. The default setting in netlogo-headless.sh uses just 1GB of RAM. Modern high-performance computers typically offer 16GB of memory or more. It is recommended to increase the amount of memory to at least 2GB or 4GB if you have access to more memory and are interested in running NetLogo more quickly. The 1GB default limit is largely to accommodate the often-limited resources of consumer and school computers, which may not have much memory to spare. Note that if you're using behaviorsearch, the behaviorsearch_headless.sh file also has a memory limit which can be increased for improved performance.

NetLogo headless will still run plots (to facilitate primitives like export-plots). Disabling plots can result in speed increases and reduce memory usage, especially if the plots involve complex code. If your NetLogo model has plots, remove those before running headlessly unless you rely on the data they generate. If you want to continue to use the plots in the "normal" version of your model, you can use NetLogo's "Save As" option to save an alternate version of the model with the plots removed.

Increasing the amount of concurrency used by NetLogo (and/or Behaviorsearch) is useful for getting more model runs. It will not increase the speed at which any one model run occurs. If you have a model which needs to be run for many steps but only needs to be run a single time increasing concurrency (via the --threads parameter) will not decrease the amount of time necessary to run your model. If you have a model which needs to be run many times, increasing concurrency is likely to decrease the amount of time it takes to complete all runs of your model. Note that the number of threads used by NetLogo if the --threads parameter is omitted will be the value returned by Runtime.availableProcessors at the time NetLogo is launched. If your model uses a large amount of memory, you may find that passing in a smaller value of --threads will cause the run to go faster since the run will require less time spent on garbage collection.