Udp payload lookup optimization

[c0pp3rdru1d]

UDP Payload Lookup Optimization

Hello,

Thank you for taking the time to review this PR. I hope this contribution adds something useful to the project. Below is a short explanation of what I observed, what was changed, and the resulting improvement.

🔍 Previous Behavior — O(n) per Port

For every scanned port, the implementation iterated through the entire:

BTreeMap<Vec, Vec>

        ┌────────────────────────────┐

Port 53 → │ Iterate entire BTreeMap │
│ │
│ [ [53,123] ] → payload A │
│ [ [161] ] → payload B │
│ [ [69] ] → payload C │
│ ... │
└────────────────────────────┘
↓
Vec::contains(port)?
↓
Assign payload (last match wins)
Per-port behavior

Walk entire map

Check every Vec using contains

Repeat for each scanned port

If scanning 4,000 ports:

The entire structure is re-scanned 4,000 times.

Complexity
O(payload_groups × ports_per_group × scanned_ports)

This makes UDP payload selection a repeated linear scan inside the scanning loop.

✅ New Behavior — O(1) per Port

The new implementation performs a one-time precomputation step:

Build HashMap<u16, Arc<[u8]>>

[53] → payload A
[123] → payload A
[161] → payload B
[69] → payload C

Then lookup becomes:

payload = hashmap.get(&port)

No iteration

No Vec::contains

No repeated scanning

Complexity
O(scanned_ports)

Lookup is now constant time per port.

📊 Benchmark Results

Isolated UDP payload lookup benchmark:

Old implementation (1..4096 ports): ~2.9 ms
New implementation (1..4096 ports): ~16 µs

This represents approximately:

~180× faster lookup

End-to-end UDP scan timing remains largely unchanged due to network I/O dominating runtime, but CPU overhead in the payload selection hot path is significantly reduced.

Behavioral Integrity is preserved.

Payload selection semantics remain unchanged!

Thank you again for your time and review. I’m happy to adjust or expand this further if needed. I think this is an awesome tool that I'll be using for my own practice.

-c0pp3rdru1d