This page is now deprecated. Please refer to the new documentation at siril.readthedocs.io.
Processor cores management
The number of processor cores used can be changed, from the graphical user interface (see the image below), or using the setcpu command. In most cases it's a good idea to use the default value, which is the number of threads advertised by the operating system, but if you want your system to be more responsive, if you use it for other purposes during processing, it may be better to lower the number.
Memory management
Siril is configured by default to use as much memory as available for stacking operations. When stacking starts, Siril looks at the available memory on the system and takes at least 90% of this amount for itself. This means that if the stacking takes a long time and that other processes are running on the system, making the available memory fluctuate (like Web browsing at the same time for example), the system may run out of memory and freeze. In this case, it would be a good idea to ask Siril to take less from the available memory. For that in the settings, Miscellaneous section, lower the ratio from the default 0.9 to maybe 0.6, depending on what you want to do at the same time. It is also possible to limit Siril's configured memory allocation to a number of gigabytes (GB), changing the combo box.
For other actions, like preprocessing, registration or normalization computation, Siril will limit itself to the worst possible case, in which all image data used by the different threads (processor cores) is allocated and used at the same time. Most often, this does not happens, as some threads process and some read or write data, but this limitation may lower the number of threads used by Siril, to not go out of memory if unlucky. Some users will want to disable this behaviour to increase the processing throughput, by setting a ratio slightly above 1 to allow Siril to use a bit more than the available memory, or again by setting a fixed number of GB.
Disk management
Processing astronomy images is a very intensive operation for the computer and puts a lot of pressure on the disks subsystems. Several images are often read at the same time and several may be written at the same time. The use of an SSD is recommended for both performance and longevity. If you are working on a spinning hard disk drive it may be a good idea to reduce the number of active threads to keep it from wearing off too quickly. Using SER or FITS cube sequences will limit images writing to one at a time.
A lot of files may be created in the current working directory (CWD), if working with sequences of FITS files. If you have many input images, you will have as many more pre-processed images, as many more registered images in case of global registration with rotation, and there could be even more. At the end of a processing it is common to have 5 times the number of input files in the directory. The intermediate sequences can all be opened from the graphical user interface to examine the effect of the previous operation, or to restart the current operation with different parameters to try to improve something. All those files can be useful, so we don't remove them. If you are satisfied with the stacking result, then it is safe to remove them, manually. With recent scripts, they are all stored in an intermediate directory named process.
Currently, Siril does not support reading from a directory (or disk) and writing to another. This could improve performance, but it is not yet available.