Skip to main content

Performance

Some general tips for optimizing the performance of rakaia sessions are provided below.

Array casting​

By default, rakaia will store imported data as 32 byte numpy float arrays. Information on numpy dtypes can be found here. To reduce memory consumption and the amount of temporary disk storage required, users can choose to have arrays stored as 16 byte unsigned integers instead by invoking the CLI option --array-type (from v0.11.0 onwards):

rakaia -at int

In many instances, using integer array types will save up to 50% of the disk space required for storing the same array in float32 format.

This option will work well for the majority of user cases, as arrays are always converted into integers when recoloured and blended in the canvas. However, there are two specific use cases where storing the arrays as float are beneficial or necessary:

  • When the channel array has values between 0 and 1: these values will automatically be converted to 0 or 1 with integer casting, so any decimal precision will be lost for this channel.
  • When the array channel has a maximum value over 65535: Unsigned 16 byte integers in numpy have a maximum positive range of 65535, so any array values that are greater will be clipped to this value

For the use cases above, users are advised to use the default float array storage type.

Hover templates​

rakaia supports custom hover templates for the canvas, which modify the information displayed when the user hovers over a pixel in the canvas. By default, only the x and y-coordinates at the hover position are displayed, but users can toggle on either raw channel values for every marker in the current blend, or the mask ID for objects in a mask if a mask is applied.

warning

Hover templates are likely to significantly reduce the speed and responsiveness of canvas-level modifications. This is particularly true for larger images (greater than a resolution of 1000x1000) that have multiple channels. This is due to the storage of the canvas hover template in an uncompressed slot within the back-end canvas figure. More specifically, it requires sending a greater amount of data to the user frontend, which causes the canvas to be slower. For example, the hover template for raw channel values will grow linearly with the number of channels in the blend if raw channel values are requested. Users should use the hover template sparingly and toggle the feature off before making additional canvas adjustments such as add/removing layers, modifying the canvas annotations, etc.

It is suggested to use the hover template only on small zoomed in regions for a quick reference, and to disable the feature before making any other canvas modifications.

Load screens​

rakaia uses loading components for specific data stores and input widgets to alert the user to the state of changing data. These include loaders for the underlying image hash table, as well as the canvas when the current ROI dimensions are sufficiently large.

Currently, rakaia will automatically wrap the main canvas in a loader when either the height or width of the canvas is greater than 3000 pixels. This threshold was set empirically by observing the average number of seconds that it takes for a canvas modification to be applied to the frontend for different ROI resolutions. When the delay is greater than a few seconds, the load screen is intended to convey the state of the application to users, and to indicate when data and components are ready for interactivity.

Users can disable the use of load screens on CLI startup with the following option:

rakaia -dl

This will likely make the entire in-app workflow smoother, however, the user will no longer be able to get feedback from the application as to the status of the canvas or other components that load and modify data. Therefore, it is recommended to use this feature only when sufficient experience with different ROI resolutions has been gained, in order to have an approximate idea of image load times for specific hardware configurations.

Production mode​

A production-level server can be invoked from the CLI:

rakaia -pr

This will generate a production-level WSGI server,and will switch the application out of debug mode. Default: not enabled. Production mode invokes a server from waitress that is intended to support concurrent users on public deployments. Because of the server configuration, debugging mode (i.e. viewing the application errors/exceptions in the console) is not available. Should be used if the user is experiencing performance issues (lag, timeouts), as removing debugging mode should in theory reduce memory consumption for the interpreter.

For architetcures with lower memory or less capable processors, using production mode with ir without integer array casting with -at int may prove useful in being able to reasonably manage ROIs of larger sizes (> 1000x1000 pixels).