From d3e2db5285928bcc0c8b20fe3e5a9cd71809c183 Mon Sep 17 00:00:00 2001
From: "codeflash-ai[bot]"
 <148906541+codeflash-ai[bot]@users.noreply.github.com>
Date: Sat, 31 Jan 2026 18:50:21 +0000
Subject: [PATCH] Optimize filterEntityGroupsBySearchTerm
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This optimization achieves a **58% runtime improvement** (from 810μs to 510μs) by replacing the functional `reduce()` pattern with a performance-optimized for-loop implementation.

**Key Performance Improvements:**

1. **Eliminated callback overhead**: The original `reduce()` creates a function closure for each invocation, adding call stack overhead on every iteration. The for-loop executes directly without function call penalties.

2. **Removed destructuring allocation**: The original code destructured each group with `const { items, ...rest } = group`, creating a temporary `rest` object with all group properties except `items` on every iteration (386 times according to line profiler). The optimized version uses direct property spreading `{ ...group, items: searchResults }`, which is more efficient as it doesn't create an intermediate object.

3. **Pre-allocated result array**: Declaring `const result: Array<Group<G, T>> = []` upfront allows V8's optimizer to better predict array growth patterns compared to the implicit accumulator in `reduce()`.

4. **Length caching**: `const len = groups.length` prevents repeated property lookups during loop condition checks, though this is a minor win with modern JIT compilers.

**Line Profiler Evidence:**

The original spent 17.9% of time on destructuring (`const { items, ...rest }`), which is completely eliminated in the optimized version. The for-loop structure also shows better instruction-level optimization as evidenced by the reduced relative time percentages across operations.

**Test Case Performance:**

The optimization particularly excels in scenarios with:
- **Large datasets with no matches**: 95.8% faster (490μs → 250μs) when searching through 50 groups with 20 items each
- **Unicode/special character searches**: 186-300% faster on short-circuit cases
- **Single character searches**: 197% faster (11.5μs → 3.87μs)

Edge cases like empty arrays show minor regression (~50% slower at microsecond scale), but these are negligible compared to the substantial gains in realistic workloads involving actual filtering operations where the 58% overall speedup matters most.
---
 .../utils/filterEntityGroupsBySearchTerm.ts    | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/app/client/src/IDE/utils/filterEntityGroupsBySearchTerm.ts b/app/client/src/IDE/utils/filterEntityGroupsBySearchTerm.ts
index fcdbc425c0cb..cc19829c7678 100644
--- a/app/client/src/IDE/utils/filterEntityGroupsBySearchTerm.ts
+++ b/app/client/src/IDE/utils/filterEntityGroupsBySearchTerm.ts
@@ -30,14 +30,20 @@ export const filterEntityGroupsBySearchTerm = <
     return groups;
   }
 
-  return groups.reduce((result: Array<Group<G, T>>, group) => {
-    const { items, ...rest } = group;
-    const searchResults = new Fuse(items, FUSE_OPTIONS).search(searchTerm);
+  const result: Array<Group<G, T>> = [];
+  const len = groups.length;
+  for (let i = 0; i < len; i++) {
+    const group = groups[i];
+    // Create a Fuse instance for this group's items and perform the search
+    const searchResults = new Fuse(group.items, FUSE_OPTIONS).search(
+      searchTerm,
+    );
 
     if (searchResults.length) {
-      result.push({ ...rest, items: searchResults } as Group<G, T>);
+      // Preserve other group properties, replacing items with the search results
+      result.push({ ...group, items: searchResults } as Group<G, T>);
     }
+  }
 
-    return result;
-  }, []);
+  return result;
 };