⚡️ Speed up function get_provider_from_variable_name by 104% in PR #10565 (model-provider-keys-v2)#10937
⚡️ Speed up function get_provider_from_variable_name by 104% in PR #10565 (model-provider-keys-v2)#10937codeflash-ai[bot] wants to merge 601 commits into
get_provider_from_variable_name by 104% in PR #10565 (model-provider-keys-v2)#10937Conversation
…ai/langflow into model-provider-keys-v2
…ai/langflow into model-provider-keys-v2
…odel-provider-keys-v2
…odel-provider-keys-v2
The optimized version achieves a **103% speedup** by replacing a linear search through a dictionary with a direct hash table lookup.
**Key optimization applied:**
- **Eliminated O(n) linear search**: The original code iterates through all provider-variable pairs using `for provider, var_name in provider_mapping.items()` until finding a match
- **Introduced O(1) hash lookup**: The optimized version pre-computes a reversed mapping `{var_name: provider}` and uses `dict.get(variable_name)` for constant-time lookups
- **Added memoization with `@lru_cache(maxsize=1)`**: The reversed mapping is cached so it's only computed once, even across multiple function calls
**Why this leads to speedup:**
In Python, dictionary `.get()` operations are O(1) average case, while iterating through dictionary items is O(n). The line profiler shows the original code spent 46.5% of time in the loop iteration and 29.1% in string comparisons. The optimized version eliminates both, reducing total runtime from 620μs to 119μs.
**Performance characteristics based on test results:**
- **Small mappings** (8-10 providers): Consistent ~2x speedup across all test cases
- **Large mappings** (1000 providers): The speedup becomes more pronounced as the linear search penalty increases
- **Cache effectiveness**: The `lru_cache` ensures that even repeated calls to `get_model_provider_variable_mapping()` don't impact performance after the first call
This optimization is particularly valuable when `get_provider_from_variable_name` is called frequently with large provider mappings, transforming what was potentially an expensive operation into a near-constant time lookup.
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the Comment |
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (31.66%) is below the target coverage (40.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #10937 +/- ##
==========================================
+ Coverage 32.60% 32.62% +0.01%
==========================================
Files 1372 1387 +15
Lines 63563 65021 +1458
Branches 9388 9643 +255
==========================================
+ Hits 20725 21210 +485
- Misses 41795 42720 +925
- Partials 1043 1091 +48
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Closing automated codeflash PR. |
⚡️ This pull request contains optimizations for PR #10565
If you approve this dependent PR, these changes will be merged into the original PR branch
model-provider-keys-v2.📄 104% (1.04x) speedup for
get_provider_from_variable_nameinsrc/backend/base/langflow/api/v1/models.py⏱️ Runtime :
80.6 microseconds→39.6 microseconds(best of166runs)📝 Explanation and details
The optimized version achieves a 103% speedup by replacing a linear search through a dictionary with a direct hash table lookup.
Key optimization applied:
for provider, var_name in provider_mapping.items()until finding a match{var_name: provider}and usesdict.get(variable_name)for constant-time lookups@lru_cache(maxsize=1): The reversed mapping is cached so it's only computed once, even across multiple function callsWhy this leads to speedup:
In Python, dictionary
.get()operations are O(1) average case, while iterating through dictionary items is O(n). The line profiler shows the original code spent 46.5% of time in the loop iteration and 29.1% in string comparisons. The optimized version eliminates both, reducing total runtime from 620μs to 119μs.Performance characteristics based on test results:
lru_cacheensures that even repeated calls toget_model_provider_variable_mapping()don't impact performance after the first callThis optimization is particularly valuable when
get_provider_from_variable_nameis called frequently with large provider mappings, transforming what was potentially an expensive operation into a near-constant time lookup.✅ Correctness verification report:
🌀 Generated Regression Tests and Runtime
To edit these changes
git checkout codeflash/optimize-pr10565-2025-12-08T21.08.36and push.