Skip to content

vendor(apptype): emit TransportProtocol.tcp instead of TransportProtocol.get(...) in 23,938 places #768

Description

@JarryShaw

Is your feature request related to a problem? Please describe.

The generated registries call TransportProtocol.get('tcp') to name a constant. There are 23,938
such calls across pcapkit/const/reg/apptype/, every one executed at class-definition time, i.e. on
every import of pcapkit. get() is a real function doing an isinstance check, key.lower()
twice, a __members__ membership test and a __getitem__ — to reach a member that plain attribute
access returns in one lookup.

Describe the solution you'd like

Emit TransportProtocol.tcp instead of TransportProtocol.get('tcp'). One line, in
pcapkit/vendor/reg/apptype/apptype.py:573-574:

return ' | '.join(f'TransportProtocol.get({proto!r})' for proto in sorted(protos, key=order.index))

Measured, on this checkout:

T.get('tcp') is T.tcp  ->  True        (same for udp / sctp / dccp / undefined)
per call:   get() 524 ns   attribute 24 ns   ->  21.4x
23,938 sites:  12.5 ms  ->  0.6 ms    ~12 ms saved per import
generated size: ~187 KB smaller (29 chars -> 21 per site)

Safe because the generator only ever emits the five declared names (TRANSPORTS + ('undefined',)),
so get()'s extend_enum fallback for an unknown name cannot fire in generated code. get() itself
stays — AppType.get(..., proto=...) and other callers need it.

Describe alternatives you've considered

Leaving it: the cost is small in absolute terms. But it is pure waste on every import, and the
explicit form also reads better — cls.__transport__ is TransportProtocol.tcp says plainly that it
is an identity comparison against a canonical member, which is the thing #732 wants to make safe.

Additional context

Note the members are lowercase: TransportProtocol.TCP raises AttributeError, since only
get() lowercases. Requested by the maintainer. Should land together with #744's one-line change to
:717 in the same file — both are mechanical and one regeneration covers both, where separate PRs
would produce conflicting ~12,000-line diffs over the same generated files.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementperfPull requests that improve performance (perf: subject prefix)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions