fix: Use correct feature name for canbench profiling

[dsarlis]

The feature that enables specific canbench profiling of some code 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.