misc: Add bytesbuf vs bytes benchmark suite for read/write operations

[Copilot]

• Restructure benchmark groups to pair bytesbuf and bytes implementations
• Use iter_custom with .iterations(iters) for efficient allocation tracking
• Fix method mapping: bytes::put_bytes() = bytesbuf::put_byte_repeated()
• Replace std::mem::size_of with size_of (in scope by default)
• Reduce benchmark count from 83 to 82 by grouping related functions
• Update benchmark group names to be workspace-friendly (bytesbuf_vs_bytes_*)
• Move data preparation outside timed loops for ALL benchmarks (GET, PUT, GET_NUM, PUT_NUM)
• All benchmarks compile and run successfully with allocation tracking

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Create "bytesbuf vs bytes" benchmark for read/write operations</issue_title>
<issue_description>In the bytesbuf crate, we have the BytesBuf and BytesView types. These implement inherent functions for reading/writing bytes (found in buf_put.rs and view_get.rs), as well as the Buf and BufMut traits from the bytes crate (via contents of bytes_compat folder), which offer similar default-implemented methods for reading/writing bytes.

Our benchmarks currently only test the inherent functions, and only a subset of these.

Create a thorough benchmark suite for comparing the two implementations, which we can use to prove that our inherent implementations do not accidentally cause performance regressions. Include all inherent read/write functions in the two files mentioned above. Include all read/write functions found on Buf and BytesBuf.

This will be a new benchmark file, bytesbuf/benches/bytesbuf_vs_bytes.rs. It will contain multiple benchmark groups: get, put, get_num and put_num. Both the bytesbuf and the bytes functions will be part of the same group, so they can be easily compared in the output (e.g. we will have both get_u64_bytesbuf and get_u64_bytes benchmarks in the get_num group).

The purpose for having _num groups is that the numeric get/put functions are very fast, whereas some others (like reading/writing entire byte slices or byte sequences) are slower. For ease of comparison, each group should only contain functions of similar expected duration, so we put all the (extremely fast) numeric value reading/writing in its own benchmark group.

Follow patterns used in existing bytesbuf benchmarks. Include memory allocation measurement via alloc_tracker, so we can prove that we do not accidentally allocate more memory than bytes.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Create "bytesbuf vs bytes" benchmark for read/write operations #151

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (ba3e6f7) to head (d70963b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #162   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files          90       90           
  Lines        6497     6497           
=======================================
  Hits         6497     6497           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sandersaares]