Optimize string lookups with index references

[ERnsTL]

Yes, there are several places in the codebase where frequent string-based lookups occur that could benefit from index-based references, particularly during message transfer operations. Here are the key locations:

1. Graph Inport/Outport Packet Delivery (High Frequency)

Location: Runtime::packet() function in src/lib.rs (~line 1523)

Current code:

if let Some(inport) = inports.get_mut(payload.port.as_str()) {
    // deliver packet
}

Impact: Every packet sent to graph inports (external data ingress) requires a HashMap lookup by port name string. This happens for every external message.

Optimization potential:

• Use HashMap<String, usize> for name-to-index mapping
• Store ports as Vec<ProcessEdgeSink> with indices
• O(1) access instead of O(log n) string hash lookup

2. Runtime Packet Broadcasting (Medium-High Frequency)

Location: send_runtime_packet() and broadcast_to_clients() in src/lib.rs

Current code:

let clients = {
    let graph_inout_locked = graph_inout.lock().expect("lock poisoned");
    graph_inout_locked
        .websockets
        .iter()
        .map(|(addr, client)| (*addr, Arc::clone(client)))
        .collect::<Vec<_>>()
};

Impact: Called whenever sending runtime:packet notifications to FBP clients (e.g., when graph ports connect/disconnect, packet flow events).

Optimization potential: Client list iteration is already O(n), but the HashMap access could be optimized.

3. Watchdog Health Checks (Regular Polling)

Location: Watchdog thread in src/lib.rs (~line 1086)

Current code:

for (name, proc) in watchdog_threadandsignal.iter() {
    // health check each process
}

Impact: Runs every 7 seconds, iterating over all processes. Uses HashMap iteration which is O(n) but could be optimized.

Optimization potential:

• Vec<Process> with HashMap<String, usize> mapping
• Direct vector iteration for health checks
• Index-based process signaling

4. FBP Protocol Message Validation (Per Message)

Location: validate_secret() and get_graph_by_name() in src/server.rs

Current code:

if let Some(expected_secret) = runtime.read().expect("lock poisoned").secrets.get(graph) {
    // validate
}

Impact: Every FBP protocol message requires graph name validation and secret checking.

Optimization potential:

• Cache graph indices
• Use HashMap<String, usize> for graph lookup
• Pre-validate common graphs

5. Graph Manipulation Operations (Design Time)

Location: Graph methods like add_node(), remove_edge() in graph operations

Current code: Extensive string-based node/edge lookups during graph editing.

Impact: Less critical since these happen during design/configuration, not runtime message transfer.

Recommended Implementation Order

Phase 1 (High Impact): Graph inport/outport packet delivery

• Change GraphInportOutportHolder.inports from HashMap<String, ProcessEdgeSink> to Vec<ProcessEdgeSink> with name-to-index mapping
• Most direct performance benefit for data ingress/egress

Phase 2 (Medium Impact): Process management

• Change ProcessManager from HashMap<String, Process> to Vec<Process> with mapping
• Benefits watchdog health checks and process signaling

Phase 3 (Lower Impact): Graph operations

• Add indices to GraphNode and edge references
• Benefits graph manipulation during OLC preparation

These changes would align with the Go issue's suggestions for index-based references while maintaining the existing lock-free message passing architecture.