Files
cal-diy-oidc/agents/rules/performance-avoid-quadratic.md
T
Benny Joo ab21c7f805 refactor: Cal.diy (#28903)
* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com

This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main:

- Rebrand Cal.com to Cal.diy across the entire codebase
- Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions
- Switch license from AGPL-3.0 to MIT
- Remove docs/ directory (migrated to Nextra at cal.diy)
- Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc.
- Clean up .env.example for self-hosted Cal.diy
- Update Docker image references to calcom/cal.diy
- Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork
- Add PR welcome bot for Cal.diy contributors
- Fix API v2 breaking changes oasdiff ignore entries
- Replace Blacksmith CI runners with default GitHub Actions

3893 files changed, 20789 insertions(+), 411020 deletions(-)

Co-Authored-By: benny@cal.com <sldisek783@gmail.com>

* refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* rip out org related comments in api v2

---------

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-04-15 09:52:36 -03:00

2.2 KiB

title, impact, impactDescription, tags
title impact impactDescription tags
Avoid O(n²) Algorithms - Design for Enterprise Scale CRITICAL Prevents performance collapse at scale performance, algorithms, complexity, scale

Avoid O(n²) Algorithms - Design for Enterprise Scale

Impact: CRITICAL

We build for large organizations and teams. What works fine with 10 users or 50 records can collapse under the weight of enterprise scale. Performance is not something we optimize later. It's something we build correctly from the start.

When building features, always ask: "How does this behave with 1,000 users? 10,000 records? 100,000 operations?"

Common O(n²) patterns to avoid:

  • Nested array iterations (.map inside .map, .forEach inside .forEach)
  • Array methods like .some, .find, or .filter inside loops or callbacks
  • Checking every item against every other item without optimization
  • Chained filters or nested mapping over large lists

Incorrect (O(n²) - exponential slowdown):

// Bad: O(n²) - checks every slot against every busy time
const available = availableSlots.filter(slot => {
  return !busyTimes.some(busy => checkOverlap(slot, busy));
});

// For 100 slots and 50 busy periods: 5,000 checks
// For 500 slots and 200 busy periods: 100,000 checks (20x increase!)

Correct (O(n log n) - scales gracefully):

// Good: O(n log n) - sort once, break early
const sortedBusy = [...busyTimes].sort((a, b) => a.start - b.start);

const available = availableSlots.filter(slot => {
  // Binary search or early exit
  const index = binarySearch(sortedBusy, slot.start);
  return !hasOverlapAt(sortedBusy, index, slot);
});

Better data structures and algorithms:

  • Sorting + early exit: Sort data once, break out of loops when remaining items won't match
  • Binary search: Use for lookups in sorted arrays instead of linear scans
  • Two-pointer techniques: For merging or intersecting sorted sequences
  • Hash maps/sets: Use for O(1) lookups instead of .find or .includes on arrays
  • Interval trees: For scheduling, availability, and range queries

Reference: Cal.diy Engineering Blog