perf: call field.__copy__() directly instead of copy.copy(self)

[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) -- scoped to the changed files; findings are pre-existing, verified against baseline
• make test passes, and a test case covers the change -- ran pytest tests/corekit/ (199 passed, 1915 subtests) plus a broader protocol/integration set (81 passed, 1 skipped, 477 subtests); did not run the full suite
• Added a changelog entry -- N/A, changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• perf — changes performance, not behaviour

---

Description

copy.copy(self) at the 8 per-field-per-packet __call__ sites still has to find FieldBase.__copy__ before calling it: getattr(cls, '__copy__', None). That lookup alone profiled at 55,846 calls (~1.7% of an extract() run) on examples/captures/http.pcap -- reproduced here exactly. copier = getattr(cls, '__copy__', None); copier(x) in copy.py is x.__copy__(), so calling it directly removes the lookup without changing when a field is copied or what the copy contains.

Skipping the copy itself (rather than just its dispatch) was considered and ruled out: NumberField/_TextField.__call__ unconditionally mutate the copy their super().__call__() returns, and OptionField.unpack mutates _option_padding on whatever __call__ handed back, so a field with no callback can still need a fresh copy for reasons unrelated to the callback.

Byte-identity verified across 17 classic-PCAP samples (1500 subtests, before and after, identical). End-to-end effect is below this host's noise floor (25-rep spread ~0.43s vs. a ~2ms expected shift); the isolated dispatch saving is real and reproducible in a tight microbenchmark (~0.58us -> ~0.42us per copy).

Fixes #730.

[JarryShaw]

✅ GOOD TO MERGE @ a4e0db9d6 — the swap is provably a no-op in semantics: CPython's copy.copy does copier = getattr(cls, "__copy__", None); return copier(x) (copy.py:80-82), and FieldBase.__copy__ (field.py:307) is the only __copy__ on any field, so calling it directly is what copy.copy already resolved to.

Cross-review ran on Opus against Sonnet-authored work and returned GOOD TO GO. Posted here by the coordinator: that reviewer was a read-only helper with no gh pr comment grant, so its verdict existed only in a hand-back report. Independently verified before posting:

Claim	Result
copy.copy(self) ≡ self.__copy__()	confirmed from installed CPython 3.14.7 copy.py:80-82
No field subclass overrides __copy__	confirmed — only field.py:307 and the unrelated multidict.py:432
8 call sites swapped, import copy dropped from all 3 files	confirmed in the diff
Copy count unchanged	this is a dispatch change, not a skip — every field is still copied as often as before

Not a "skip the copy when callbacks are trivial" change, and the author was right to reject that: NumberField.__call__ and _TextField.__call__ unconditionally rewrite _template on whatever super().__call__() returns, so returning self would corrupt the class-level Schema.__fields__ descriptor.

Two caveats carried forward honestly from the author rather than dropped:

• End-to-end gain is unmeasurable, and the PR says so: ~2 ms mean difference against a 0.43 s run-to-run spread over 25 reps. The real figure is the isolated mechanism — 0.580 µs → 0.420 µs per copy, ~28%, ~9 ms aggregate over 55,846 copies.
• Pre-existing inconsistency, deliberately untouched: ListField.__call__ passes the original self to _callback, not new_self, unlike every other site. Out of scope here; changing it would be a behaviour change rather than a dispatch one.

✅ GOOD TO MERGE @ a4e0db9d6 — pending its CI, which is still queued.