Skip to content

Commit e14f31b

Browse files
committed
docs: document pre-computing optimizations
- Explain the O(N^2) to O(N log N) improvement via pre-sorting in common_prefix - Detail the O(N^2) to O(N) transition using set lookups in count_letters - Summarize the Space-vs-Time trade-offs applied to both algorithms - Note the preservation of legacy variable names and helper functions
1 parent a35d066 commit e14f31b

1 file changed

Lines changed: 46 additions & 0 deletions

File tree

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
# Changes Made: Optimization via Pre-computing
2+
3+
## Overview
4+
These changes apply the strategy of **Pre-computing**: doing work upfront (like sorting or indexing) to make the primary search or calculation significantly faster. This allowed both algorithms to scale from small examples to datasets containing millions of items.
5+
6+
---
7+
8+
## 1. Longest Common Prefix Optimization (`common_prefix.py`)
9+
10+
### The Problem
11+
The original implementation used a nested loop to compare every string in a list against every other string.
12+
- **Original Complexity**: $O(N^2)$.
13+
- **The Bottleneck**: With 1,000,000 strings, the code would perform roughly 1 trillion comparisons, causing it to hang indefinitely.
14+
15+
### The Solution: "Sort Before Search"
16+
I implemented alphabetical sorting as a pre-computation step.
17+
- **Why it works**: In a sorted list, the strings that share the longest common prefixes are mathematically guaranteed to be **neighbors**.
18+
- **The Change**: By sorting the list first, I replaced the nested loop with a single pass that only compares each string to the one immediately following it.
19+
- **Improved Complexity**: $O(N \log N)$ for the sort + $O(N)$ for the single-pass search.
20+
- **Legacy Retention**: Kept the original `find_common_prefix` helper function and variable names (`longest`, `string`, `other_string`) to maintain code continuity.
21+
22+
---
23+
24+
## 2. Count Letters Optimization (`count_letters.py`)
25+
26+
### The Problem
27+
The original code contained a "hidden loop" inside a string iteration.
28+
- **Original Complexity**: $O(N^2)$.
29+
- **The Bottleneck**: The check `if letter.lower() not in s` required the computer to scan the entire string `s` for every character. On a 10-million-character string, this resulted in an impossible amount of work.
30+
31+
### The Solution: "Sets for Instant Lookups"
32+
I introduced a pre-computed **Set** to handle character lookups.
33+
- **Why it works**: Searching for an item in a Python `set` (a hash table) takes **O(1) constant time**, whereas searching a `string` takes **O(N) linear time**.
34+
- **The Change**: I converted the string `s` into a set (`chars_in_string`) at the start of the function. This one-time $O(N)$ operation transformed the inner search from a slow scan into an instant lookup.
35+
- **Improved Complexity**: $O(N)$ — one pass to build the set, and one pass to loop through the string.
36+
- **Legacy Retention**: Preserved the original loop structure (`for letter in s`), the `is_upper_case` helper, and the `only_upper` variable name.
37+
38+
---
39+
40+
## 3. Technical Trade-offs: Space vs. Time
41+
Both tasks are classic examples of the **Space-vs-Time trade-off**:
42+
43+
1. **Memory (Space)**: We used extra memory to store a sorted version of the list (Task 5) and a set of unique characters (Task 6).
44+
2. **Speed (Time)**: By "spending" this memory, we drastically reduced the number of CPU operations required.
45+
46+
**Result**: Operations that previously would have taken hours now complete in milliseconds, representing a massive gain in software scalability and performance.

0 commit comments

Comments
 (0)