Optimize parameter matching in TableMetaDataContext

[belljun3395]

Optimize parameter matching in TableMetaDataContext

Problem

The TableMetaDataContext.matchInParameterValuesWithInsertColumns() method uses a nested loop for case-insensitive parameter matching, resulting in O(n×m) complexity where n = columns and m = parameters.

For each column, when exact matching fails, it iterates through all parameter entries to find case-insensitive matches:

for (String column : this.tableColumns) {                    // O(n)
    Object value = inParameters.get(column);
    if (value == null) {
        // ... lowercase lookup
        if (value == null) {
            for (Map.Entry<String, ?> entry : inParameters.entrySet()) {  // O(m)
                if (column.equalsIgnoreCase(entry.getKey())) {
                    value = entry.getValue();
                    break;
                }
            }
        }
    }
    values.add(value);
}

This becomes expensive with many columns and parameters (e.g., 100 columns × 1000 parameters = 100K iterations).

Solution

Pre-compute a case-insensitive lookup map, reducing complexity from O(n×m) to O(n+m):

// Build lookup map once - O(m)
Map<String, Object> caseInsensitiveLookup = new HashMap<>(inParameters.size());
for (Map.Entry<String, ?> entry : inParameters.entrySet()) {
    caseInsensitiveLookup.put(entry.getKey().toLowerCase(Locale.ROOT), entry.getValue());
}

for (String column : this.tableColumns) {  // O(n)
    Object value = inParameters.get(column);
    if (value == null) {
        value = inParameters.get(column.toLowerCase(Locale.ROOT));
        if (value == null) {
            value = caseInsensitiveLookup.get(column.toLowerCase(Locale.ROOT)); // O(1)
        }
    }
    values.add(value);
}

Performance Impact

• Before: O(n×m) - quadratic growth
• After: O(n+m) - linear growth
• Applications affected: SimpleJdbcInsert users with many columns/parameters

Testing

• ✅ All existing tests pass (no behavior change)
• ✅ Verified case-sensitive/insensitive matching logic preserved

[mdeinum]

Spring itself provides a LinkedCaseInsensitiveMap which provides this functionality already. Wouldn't it be easier to use that, it seems to be used in other places in the JDBC access already.

[belljun3395]

I've updated the implementation to use LinkedCaseInsensitiveMap instead of manually creating a case-insensitive lookup map. The changes are available in commit cdb149b

[mdeinum]

When using the LinkedCaseInsensitiveMap you can just do a regular get without the need to convert to lowercase (the map will take care of this). Which would simplify this code.

[belljun3395]

Thanks for highlighting the existing implementation examples I overlooked, and I appreciate the review!

[belljun3395]

I've updated the implementation to use LinkedCaseInsensitiveMap instead of manually creating a case-insensitive lookup map. The changes are available in commit cdb149b

[bclozel]

This looks good overall but I'm wondering if this isn't a typical cpu vs. memory tradeoff.
The first lookup is done against inParameters.get(column.toLowerCase(Locale.ROOT)); and we only fall back to a case insensitive lookup if nothing was found.

Depending on the most common situation here, one could consider that creating a new Map instance with thousands of entries for a fallback operation that is barely used is a performance regression.

When is this particular fallback being used @belljun3395 , maybe you encountered a performance issue in your application and can share more about what happened?

Thanks!