java-topology/docs/tickets/seaorm-0003-sorted-tables-vec-contains.md

seaorm-0003: sorted_tables fallback — O(N²) Vec::contains in loop

Severity: MEDIUM File: src/schema/builder.rs Line: 238 Status: PATCHED

Description

SchemaBuilder::sorted_tables performs a topological sort of registered entity tables. When the sort does not consume all entities (cyclic foreign keys), leftover entities are appended via:

for entity in self.entities.iter() {
    let table_name = get_table_name(entity.table.get_table_name());
    if !sorted.contains(&table_name) {   // O(|sorted|) per iteration
        sorted.push(table_name);
    }
}

sorted is a Vec<TableName> and contains performs a linear equality scan. With N entities and a fully-cyclic schema (worst case, common in legacy schemas), every entity falls into the fallback path and the total work is O(N²).

Root Cause

sorted is accumulated as a plain Vec. There is no auxiliary set to support O(1) membership tests during the dedup pass.

Fix

Use a HashSet (or convert sorted to index into a HashSet shadow):

let mut sorted: Vec<TableName> = Vec::new();
let mut sorted_set: std::collections::HashSet<TableName> = Default::default();

while let Some(i) = sorter.pop() {
    sorted_set.insert(i.clone());
    sorted.push(i);
}
if sorted.len() != self.entities.len() {
    for entity in self.entities.iter() {
        let table_name = get_table_name(entity.table.get_table_name());
        if sorted_set.insert(table_name.clone()) {   // O(1)
            sorted.push(table_name);
        }
    }
}

Speedup

~100x at N=500 (125 000 comparisons → 500 hash lookups)