Performance Improvement Ideas

[Jarbuckle]

The following are some ideas that @froyo-np and myself have been discussing in light of recent efforts to improvement load-time improvements for V3 OME-Zarr files.

Decoding in the Workers

Proposal
Currently, only the loading of raw byte data is handled within the workers of the Worker Pool. This leaves the decoding of that byte data to the main thread (handled by Zarrita), which slows down loading and rendering of the decoded data.

Positives
Very likely to significantly improve loading/rendering performance, especially for STPT images or other images with significant Z depth.

Negatives
Enabling this will depend on being able to either:

a) move the cache down to the level of each worker, or
b) move the cache up outside of the Zarrita Store.

This is due to the fact that the Zarrita Store performs the decoding after calling the extensible portion of its interface (get/getRange methods), and there is no publicly-available function to call to determine the a valid cache key for the range request. This latter reason prevents us from using the ranges as cache keys for a higher-level cache.

Distributed Cache

Proposal
For reasons described above, currently the cache must reside at or below the level of the Zarrita Store's get/getRange methods. Assuming this limitation has no straightforward workaround (none yet has been identified), this proposal aims to make the cache distributed, breaking apart the various slices of the identified Zarr file into large virtual "chunks" that are each owned by a specific worker (or set of workers). This could then allow the workers to perform the full load -> decode -> render stack of operations.

Positives
Likely to enable other performance improvements.

Negatives
Significant complexity involved in implementing this robustly.

Examples include:

• Cleanly separating the Zarr file into virtual chunks
• Worker lifecycle management
• Child worker management (if needed)

Rendering in the Workers

Proposal
Using WebGPU, transfer rendering to the workers that load the data, resulting in a single stack of load -> decode -> render in a single thread.

Positives
Avoids any likelihood of rendering interruptions of the event loop.

Negatives
Not always a valid construct for rendering: won't usually work for datasets where order of rendering matters (such as Scatterbrain). Also only available within a WebGPU context.

Dedicated Rendering Worker

Proposal
Using WebGPU, transfer final rendering/compositing responsibilities to a separate worker from the main thread.

Negatives
Avoids any likelihood of rendering interruptions of the event loop. Also only available within a WebGPU context.

[lanesawyer]

there is no publicly-available function [in Zarrita] to call to determine the a valid cache key for the range request

Maybe we could see if the Zarrita project would accept a PR to expose this information? That could change the possibilities substantially if we could enhance the library.