fix: Use correct feature name for canbench profiling

[dsarlis]

The feature that enables specific canbench profiling of scoped code parts is named canbench-rs in Cargo.toml since a while ago. It seems that some of these were missed when the other cases were updated.

[Copilot]

Pull Request Overview

This PR corrects the feature flag used for canbench profiling to match the intended feature name defined in Cargo.toml.

• Update feature flag from "canbench" to "canbench-rs" in node_load and node_save functions in both v1 and v2 nodes
• Ensures that the profiling is only enabled when the correct feature is activated

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/btreemap/node/v2.rs	Updated feature flag in node_load_v2 and save_v2
src/btreemap/node/v1.rs	Updated feature flag in node_load_v1 and save_v1

[dsarlis]

Seems there's an issue with using scopes that can be repeated in benchmarks (e.g. when you call load multiple times) that I will need to figure out.

[maksymar]

Seems there's an issue with using scopes that can be repeated in benchmarks (e.g. when you call load multiple times) that I will need to figure out.

I had that issue too. Initially I thought to create a key-value storage to record measurements for each unique scope. but it was adding too much of measurement overhead.

so I went with another approach, to record the name and timestamp data point (the fastest I came up with) and only do a post-processing to aggregate time spans for each scope when printing the stats.

see #274

[dsarlis]

Seems there's an issue with using scopes that can be repeated in benchmarks (e.g. when you call load multiple times) that I will need to figure out.

I had that issue too. Initially I thought to create a key-value storage to record measurements for each unique scope. but it was adding too much of measurement overhead.

so I went with another approach, to record the name and timestamp data point (the fastest I came up with) and only do a post-processing to aggregate time spans for each scope when printing the stats.

see #274

I was thinking that the right solution would be for canbench to allow repeated scopes. Isn't that something that others might potentially need/be restricted by? Would everyone need to implement their own custom solution like you did?

[dsarlis]

Seems there's an issue with using scopes that can be repeated in benchmarks (e.g. when you call load multiple times) that I will need to figure out.

I had that issue too. Initially I thought to create a key-value storage to record measurements for each unique scope. but it was adding too much of measurement overhead.
so I went with another approach, to record the name and timestamp data point (the fastest I came up with) and only do a post-processing to aggregate time spans for each scope when printing the stats.
see #274

I was thinking that the right solution would be for canbench to allow repeated scopes. Isn't that something that others might potentially need/be restricted by? Would everyone need to implement their own custom solution like you did?

I've got a draft in canbench that allows a repeated scope to cover the cases of loops or a function be called repeatedly. I think that's a better approach to deal with this instead of canbench users trying to go around it.

[github-actions]

canbench 🏋 (dir: .) 41d6ec5 2025-05-16 12:44:47 UTC

✅ ./canbench_results.yml is up to date
📦 canbench_results_benchmark.csv available in artifacts

---------------------------------------------------

Summary:
  instructions:
    status:   Regressions detected! 🔴
    counts:   [total 124 | new 0 | improved 0 | regressed 98 | unchanged 26]
    change:   [min 0 | med +79.27 M | max +163.44 M]
    change %: [min 0.00% | med +9.06% | max +34.25%]

  heap_increase:
    status:   Regressions detected! 🔴
    counts:   [total 124 | new 0 | improved 0 | regressed 40 | unchanged 84]
    change:   [min 0 | med 0 | max +52]
    change %: [min 0.00% | med 0.00% | max +inf%]

  stable_memory_increase:
    status:   No significant changes detected 👍
    counts:   [total 124 | new 0 | improved 0 | regressed 0 | unchanged 124]
    change:   [min 0 | med 0 | max 0]
    change %: [min 0.00% | med 0.00% | max 0.00%]

---------------------------------------------------
Successfully saved CSV results to canbench_results.csv

[dsarlis]

Detailed results of the change where it can be confirmed that a constant overhead is added due to counting the scopes again, so the regressions are expected. The overhead results in higher % regression on cheap operations like get, and lower % regressions on expensive operations like insert.