Performance PRs: profile before you optimize

[domcyrus]

A note for current and prospective contributors.

RustNet aims to stay small and fast, and "fast" attracts performance PRs. Those are welcome — but I want to be explicit about the bar, so we do not spend each other's time on changes that look faster in a microbenchmark but do not move the needle in practice.

The core issue: a microbenchmark proves a function got faster in isolation. It says nothing about whether that function is hot enough to matter for overall runtime. Optimizing a cold path (connection setup, one-time parsing, error handling) just adds review and maintenance cost for no real gain.

What I ask for a performance-motivated PR:

1. Profile first. Capture a flamegraph under real traffic (see PROFILING.md) and confirm the code you are changing actually shows up as meaningful CPU time.
2. Treat benchmarks as supporting evidence, not proof. A cargo bench / criterion comparison showing your change is faster is genuinely useful and welcome — it just does not, on its own, establish that the code is on a hot path.
3. Expect cold-path micro-optimizations to be closed with thanks. Correct but cold optimizations are not free; they cost review time and add complexity to code that rarely runs.

The same guidance is now captured in CONTRIBUTING.md under "Performance & Optimizations" (EN and zh-CN).

Feedback on this is welcome.