Add basic structure for asv performance measurement

[Czaki]

Based on napari asv (https://asv.readthedocs.io/en/v0.6.1/) configuration, I have created initial configuration for this project.

Added benchmarks are only for adding structure. After review of the code, I'm not sure where I should start with benchmarks.

[LucaMarconato]

Ah no the problem is not with mamba, but that we need to run asv in main first. I'll revert my commit.

[Czaki]

Ah no the problem is not with mamba, but that we need to run asv in main first. I'll revert my commit.

No problem is with lack of definition of release commit (it point to main, instead of commit hash).

When you plan to do next release? I will create separate PR to improve release process and fix lack of this information.

[LucaMarconato]

@Czaki I checked the code and it looks great to me! I have noticed that in a few places there seems to be some redundancy in some configuration that could lead to problems in the future if we are not careful when making changes.

For instance I see that Python 3.11 is specified manually in asv.conf.json, benchmarks.yml. I could imagine that forgetting to change all of them at the same time could lead to subtle errors. Instead of "centralizing" this information, I would suggest to address this by writing in this PR a explanation/checklist (it can be very small, like 5-10 lines of text) of how to use asv for our dev purposes and what to do when something needs to be changed.

Example checklist on how to add/edit benchmarks:

• remember to split qt and non-qt tests
• before committing, test locally with asv ...
• if you change the Pyhton version, change it in asv.conf.json and benchmarks.yml

WDYT?

[LucaMarconato]

Probably we will be doing a release of spatialdata and spatialdata-plot within 2 weeks. In napari-spatialdata we could make it if needed, also today.

[Czaki]

Could you check readme now?

[LucaMarconato]

Looks great, thanks!