net_profiler_rust 0.8 vs 0.7: more coverage with little overhead

net_profiler_rust 0.8 is a reliability release. The interesting question is not only what changed, but what it costs compared with 0.7.

I compared the releaseV0.7 tag with the 0.8 release candidate on master using the same Docker-based ASP.NET Core KPI harness. The table and chart below use the median of three runs. That matters because one early run showed a large CPU spike that did not reproduce in follow-up runs.

What changed since 0.7

The 0.8 work is focused on broader runtime coverage, safer instrumentation, and better release confidence:

• .NET Framework 4.8 support, including Azure Web Apps execution and smoke-test deployment assets
• ASP.NET Core startup instrumentation before WebApplicationBuilder.Build() makes the service collection read-only
• shared original-IL body caching so multiple instrumentation paths can reuse the same original method body allocation
• SmallVec<[u8; 8]> for IL operand bytes, avoiding heap allocations for the common fixed-size ECMA-335 operands
• RAII/lifetime cleanup around profiler state and native callback handling
• restored optional pytest integration and KPI tests in CI
• controlled shutdown support for the ASP.NET MVC sample, so integration and KPI runs can stop the sample process cleanly
• stricter CI quality gates: Rust formatting, Clippy, unit tests, advisory checks, and dependency-source policy checks

KPI comparison: 0.7 vs 0.8

The median process-level memory and CPU numbers are close:

So the short version is: 0.8 adds more coverage and stronger validation, while the measured additional process overhead stays small in this smoke benchmark. Memory is effectively flat, and CPU is within the range where runner/container noise still matters.

Did SmallVec reduce memory usage?

I checked the actual 0.7-to-0.8 change. In 0.7, each IL Operand stored its bytes in a Vec<u8>. In 0.8, crates/profiler-il/src/il/utils.rs uses:

pub type OperandData = SmallVec<[u8; 8]>;

That means the normal fixed-size IL operands, usually 0, 1, 2, 4, or 8 bytes, can be kept inline in the Operand object instead of allocating a separate heap buffer.

That is still a useful cleanup, but this KPI does not show a process-level RSS reduction from it. The measured peak RSS is slightly higher in 0.8: +2.7 MB in the balanced policy and +1.5 MB in the strict policy. That does not mean SmallVec failed; it means the whole-process startup RSS signal is too coarse to isolate a small per-operand allocation improvement, especially when the same release also adds original-IL caching, broader instrumentation coverage, .NET Framework support, and more testability code.

So I would describe the result carefully:

• SmallVec should reduce small transient heap allocations while parsing and rewriting IL operands.
• The current KPI does not prove a visible RSS win from that change.
• The net 0.8 release overhead remains minimal at process level.

Takeaway

0.8 is not a raw performance release. It is a safer and broader release: more runtime coverage, better ASP.NET Core startup behavior, better CI, and cleaner test shutdown. The measured cost versus 0.7 is small enough that I would treat it as acceptable for this release, while using a dedicated allocation benchmark if we want to quantify the SmallVec effect directly.