Skip to content

MARISSA MOLEJON | OCT2025-1 | Module-Complexity | Sprint 1 | Refactor/javascript complexity analysis - #2

Open
marissamolejon wants to merge 5 commits into
mainfrom
refactor/javascript-complexity-analysis
Open

MARISSA MOLEJON | OCT2025-1 | Module-Complexity | Sprint 1 | Refactor/javascript complexity analysis#2
marissamolejon wants to merge 5 commits into
mainfrom
refactor/javascript-complexity-analysis

Conversation

@marissamolejon

Copy link
Copy Markdown
Owner

Summary

Analyzes the time and space complexity of all four Sprint 1 JavaScript
functions, documents the findings in JSDoc comments, and refactors the
functions where the complexity could genuinely be improved.

Closes #3

Changes made

Function Before After Change type
calculateSumAndProduct O(n) time, O(1) space O(n) time, O(1) space Merged two sequential loops into one pass. Same Big O class (constant factors are dropped in Big O), but halves the actual operation count.
findCommonItems O(n·m) time O(n+m) time Replaced Array.includes() (O(m) per call) with a Set.has() lookup (O(1) per call) built from the second array up front.
hasPairWithSum O(n²) time O(n) time Replaced nested-loop pairwise comparison with a single pass using a Set to check each number's complement (target - num).
removeDuplicates O(n²) time O(n) time Replaced the inner linear scan through the result array with a Set for O(1) membership checks, preserving order of first occurrence.

All four functions now have complete JSDoc blocks documenting Time
Complexity, Space Complexity, and Optimal Time Complexity, with brief
reasoning for each.

Testing

All existing tests pass unchanged for every function — no test files
were modified, since the goal was to make each function more efficient
without changing its observable behavior.

Ran locally:

  • node calculateSumAndProduct.test.js
  • node findCommonItems.test.js
  • node hasPairWithSum.test.js
  • node removeDuplicates.test.mjs

Learning points

  • Two sequential O(n) loops are still O(n) overall (Big O drops constant
    factors) — this is different from nested loops, where one loop's work
    is repeated inside every iteration of another, which multiplies rather
    than adds.
  • Array.includes() and Array.indexOf() are O(n) per call because they
    scan linearly; calling them inside another loop creates O(n²)-style
    behavior even when it doesn't look like a "classic" nested loop.
  • Swapping a linear-scan lookup for a Set-based lookup is a recurring,
    reusable pattern for turning O(n²) algorithms into O(n) — used it here
    in hasPairWithSum and removeDuplicates, and a close variant
    (Set-from-the-second-array) in findCommonItems.
  • Not every "inefficient-looking" function needs restructuring —
    calculateSumAndProduct was already O(n); the refactor there was a
    readability/constant-factor improvement, not an algorithmic one, and
    it's worth being explicit about that distinction rather than overselling
    a small change.

Checklist

  • All tests pass
  • Complexity documented for every function
  • No test files modified
  • Commit history follows Conventional Commits
  • Self-reviewed for readability, naming, and duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Analyse and Refactor Functions

1 participant