String Compression Algorithms: Efficient String Processing

1. Introduction and Core Concepts

String compression algorithms are a fundamental class of techniques in computer science designed to reduce the size of textual data by eliminating redundancy and encoding information more efficiently. At their core, these algorithms transform a string from its naive representation into a more compact form that requires fewer bits or characters to store and transmit, while preserving the ability to perfectly reconstruct the original data when needed. The target keyword, string compression algorithms, encompasses a broad family of lossless methods that are essential for efficient string processing in modern computing systems.

The importance of string compression extends far beyond simple storage savings. In an era where applications handle massive volumes of textual data — from log files and JSON payloads to genomic sequences and natural language corpora — the ability to compress strings efficiently directly impacts performance, cost, and scalability. Without compression, web servers would transmit unnecessarily large responses, databases would consume excessive disk space, and network protocols would suffer from higher latency and bandwidth costs. Effective compression reduces I/O operations, improves cache utilization, and enables faster data transfer across distributed systems.

To understand string compression, we must distinguish between two primary categories: lossless and lossy compression. String compression algorithms are almost exclusively lossless, meaning the decompressed output is bit-for-bit identical to the original input. This is critical for text, source code, and structured data where even a single character change can alter meaning. Lossless compression works by exploiting two key properties of strings: statistical redundancy, where certain characters or patterns appear more frequently than others, and repetitive structure, where substrings repeat throughout the text. Concepts such as entropy, defined by Shannon's information theory, provide the theoretical lower bound for how much a string can be compressed based on the predictability of its symbols.

Why Redundancy Matters

Natural language and structured data are highly redundant. In English text, the letter 'e' appears far more often than 'z', and common substrings like "the", "ing", or "http://" repeat frequently. A naive fixed-length encoding, such as ASCII which uses 8 bits per character, wastes space by assigning the same cost to rare and common symbols. String compression algorithms capitalize on this redundancy by using variable-length codes, dictionary references, or run-length representations to assign shorter encodings to frequent patterns.

Key Terminology

Several terms are central to this field. An alphabet is the set of distinct symbols in the input, a codeword is the compressed representation of a symbol or substring, and the compression ratio is the metric defined as compressed size divided by original size — lower values indicate better compression. The dictionary in dictionary-based methods stores previously seen substrings for reuse, while entropy encoding refers to techniques that approach the Shannon limit by encoding symbols based on their probabilities.

2. How It Works — Detailed Mechanism and Theory

String compression algorithms operate on three foundational principles: run-length reduction, statistical encoding, and dictionary substitution. While each family implements these principles differently, they all follow a common pipeline: analyze the input string to model its structure, generate a compact encoding based on that model, and produce an output that can be deterministically decoded.

Run-Length Encoding (RLE) is the simplest mechanism. It scans the input sequentially and replaces consecutive repetitions of the same character with a single instance followed by a count. For example, the string "aaabbbcccaaa" becomes "a3b3c3a3". This method is highly effective for data with long runs, such as bitmap images or sparse strings, but can actually expand data if runs are short. Its operation is purely local and requires no prior knowledge of the character distribution.

Statistical or entropy-based methods, most notably Huffman Coding, take a global view of the string. The algorithm first computes the frequency of each character, then builds an optimal prefix-free binary tree where more frequent characters receive shorter binary codes. This is achieved by repeatedly merging the two least frequent nodes using a priority queue. Because no codeword is a prefix of another, decoding is unambiguous without delimiters. Huffman coding is provably optimal among all prefix codes for a given frequency distribution and forms the backbone of many modern compressors like DEFLATE and JPEG.

Dictionary-Based Methods

Dictionary-based algorithms, including the Lempel-Ziv family (LZ77, LZ78, LZW), exploit repeated substrings rather than single-character frequencies. LZ77 uses a sliding window consisting of a search buffer (already processed text) and a look-ahead buffer (upcoming text). It encodes the next segment as a triplet (offset, length, next_char), where offset is the distance back to a previous match and length is the match size. LZ78 and LZW build an explicit dictionary of phrases, adding new entries for each new substring encountered and replacing future occurrences with fixed-length dictionary indices. These methods adapt dynamically without needing a precomputed frequency table.

The Role of Transformation

Advanced pipelines often include a transformation stage before encoding. The Burrows-Wheeler Transform (BWT) reversibly permutes the string to group similar characters together, creating longer runs that are then highly compressible with RLE and entropy coding. Similarly, Move-to-Front coding converts the transformed output into small integers, further improving compression. This layered approach — transform plus encode — is what powers high-ratio compressors like bzip2.

3. Implementation — Python Code Examples with Detailed Comments

Implementing string compression algorithms in Python provides clear insight into their trade-offs and practical considerations. The following examples demonstrate four canonical approaches, with careful attention to edge cases, efficiency, and correctness. Note that production systems would operate on bytes rather than Python strings for maximum performance, but the logic remains identical.

Example 1: Run-Length Encoding (RLE)

RLE is ideal for introducing compression logic due to its simplicity. The implementation below handles both compression and decompression, with an optimization to only emit counts greater than one to avoid unnecessary expansion.

def rle_compress(s: str) -> str:
    """Compress string using Run-Length Encoding.
    Example: 'aaabcccccaaa' -> 'a3b1c5a3' (or 'a3bc5a3' optimized)
    """
    if not s:
        return ""
    
    compressed = []
    n = len(s)
    i = 0
    
    while i < n:
        current_char = s[i]
        count = 1
        # Count consecutive occurrences
        while i + count < n and s[i + count] == current_char:
            count += 1
        
        compressed.append(current_char)
        # Only append count if > 1 to save space for single chars
        if count > 1:
            compressed.append(str(count))
        
        i += count
    
    result = "".join(compressed)
    # Return original if compression does not help
    return result if len(result) < len(s) else s

def rle_decompress(s: str) -> str:
    """Decompress RLE-encoded string."""
    if not s:
        return ""
    
    decompressed = []
    i = 0
    n = len(s)
    
    while i < n:
        char = s[i]
        i += 1
        count_str = ""
        # Parse multi-digit counts (e.g., 'a12')
        while i < n and s[i].isdigit():
            count_str += s[i]
            i += 1
        
        count = int(count_str) if count_str else 1
        decompressed.append(char * count)
    
    return "".join(decompressed)

# Test
print(rle_compress("aaabcccccaaa"))  # Output: a3bc5a3
print(rle_decompress("a3bc5a3"))      # Output: aaabcccccaaa

Example 2: Huffman Coding with Priority Queue

Huffman coding requires building a binary tree and generating prefix codes. This implementation uses heapq for efficient tree construction and recursion for code generation.

import heapq
from collections import Counter, defaultdict

class HuffmanNode:
    def __init__(self, char, freq):
        self.char = char
        self.freq = freq
        self.left = None
        self.right = None
    
    # For heap comparison: smaller freq has higher priority
    def __lt__(self, other):
        return self.freq < other.freq

def build_huffman_tree(text: str):
    """Build Huffman tree from character frequencies."""
    if not text:
        return None
    
    freq_map = Counter(text)
    heap = [HuffmanNode(char, freq) for char, freq in freq_map.items()]
    heapq.heapify(heap)
    
    # Edge case: single unique character
    if len(heap) == 1:
        node = heap[0]
        merged = HuffmanNode(None, node.freq)
        merged.left = node
        return merged
    
    while len(heap) > 1:
        left = heapq.heappop(heap)
        right = heapq.heappop(heap)
        merged = HuffmanNode(None, left.freq + right.freq)
        merged.left = left
        merged.right = right
        heapq.heappush(heap, merged)
    
    return heap[0]

def generate_codes(node, prefix="", code_map=None):
    """Recursively generate prefix codes from Huffman tree."""
    if code_map is None:
        code_map = {}
    
    if node is None:
        return code_map
    
    # Leaf node
    if node.char is not None:
        code_map[node.char] = prefix if prefix else "0"
    
    if node.left:
        generate_codes(node.left, prefix + "0", code_map)
    if node.right:
        generate_codes(node.right, prefix + "1", code_map)
    
    return code_map

def huffman_compress(text: str):
    """Return encoded bitstring and code map for decoding."""
    root = build_huffman_tree(text)
    codes = generate_codes(root)
    encoded = "".join(codes[ch] for ch in text)
    return encoded, codes, root

# Example
text = "abracadabra"
encoded, codes, tree = huffman_compress(text)
print(f"Codes: {codes}")
print(f"Encoded: {encoded} (len={len(encoded)} vs {len(text)*8} bits raw)")

Example 3: LZW Dictionary Compression

LZW is widely used in GIF and early compress utilities. It starts with a dictionary of single characters and dynamically adds new phrases.

def lzw_compress(uncompressed: str):
    """Compress string using LZW algorithm. Returns list of codes."""
    # Initialize dictionary with all single characters (0-255 for extended ASCII)
    dict_size = 256
    dictionary = {chr(i): i for i in range(dict_size)}
    
    w = ""
    result = []
    
    for c in uncompressed:
        wc = w + c
        if wc in dictionary:
            w = wc
        else:
            result.append(dictionary[w])
            # Add new phrase to dictionary
            dictionary[wc] = dict_size
            dict_size += 1
            w = c
    
    if w:
        result.append(dictionary[w])
    
    return result

def lzw_decompress(compressed):
    """Decompress list of codes to string."""
    dict_size = 256
    dictionary = {i: chr(i) for i in range(dict_size)}
    
    if not compressed:
        return ""
    
    w = dictionary[compressed[0]]
    result = [w]
    
    for k in compressed[1:]:
        if k in dictionary:
            entry = dictionary[k]
        elif k == dict_size:
            # Special case for KwKwK pattern
            entry = w + w[0]
        else:
            raise ValueError(f"Bad compressed k: {k}")
        
        result.append(entry)
        # Add new entry to dictionary
        dictionary[dict_size] = w + entry[0]
        dict_size += 1
        w = entry
    
    return "".join(result)

# Test
compressed = lzw_compress("TOBEORNOTTOBEORTOBEORNOT")
print(compressed)
print(lzw_decompress(compressed))

Example 4: In-Place String Compression (Optimized for Interviews)

This variant compresses a character array in-place with O(1) extra space, a common interview constraint. It returns the new length of the compressed array.

def compress_in_place(chars):
    """LeetCode 443 style: compress chars in-place, return new length.
    Example: ['a','a','b','b','c','c','c'] -> ['a','2','b','2','c','3'], len 6
    """
    if not chars:
        return 0
    
    write = 0  # Position to write next compressed char
    read = 0   # Position to read original chars
    n = len(chars)
    
    while read < n:
        char = chars[read]
        count = 0
        
        # Count run length
        while read < n and chars[read] == char:
            read += 1
            count += 1
        
        # Write character
        chars[write] = char
        write += 1
        
        # Write count digits if > 1
        if count > 1:
            for digit in str(count):
                chars[write] = digit
                write += 1
    
    return write

# Demo
chars = list("aaabcccccaaa")
new_len = compress_in_place(chars)
print(chars[:new_len])  # ['a', '3', 'b', '1', 'c', '5', 'a', '3'] -> optimized to ['a','3','b','c','5','a','3']
print("".join(chars[:new_len]))

4. Step-by-Step Example — Walk Through a Concrete Example

To solidify understanding, let us walk through two concrete examples: Run-Length Encoding on a simple repetitive string and Huffman coding on a more varied string. These step-by-step traces illustrate exactly how the algorithms transform input to output and why they succeed or fail depending on data characteristics.

Consider the input string S = "aaabcccccaaa" with length 12. For RLE, we initialize an empty output and scan left to right. At index 0, we encounter 'a' and count 3 consecutive 'a's before hitting 'b'. We emit "a3" and advance to index 3. At index 3, we find a single 'b', so we emit "b" or "b1" depending on optimization; the optimized version emits just "b" to avoid expansion. At index 4, we count 5 consecutive 'c's, emitting "c5". Finally, at index 9, we count 3 trailing 'a's, emitting "a3". The final compressed string is "a3bc5a3" with length 7, achieving a compression ratio of 7/12 ≈ 0.58. Decompression reverses this by reading each character and repeating it according to the following digits.

Now consider Huffman coding for S = "ABRACADABRA", which has frequencies: A:5, B:2, R:2, C:1, D:1. The algorithm begins by creating leaf nodes for each character and inserting them into a min-heap ordered by frequency. The two smallest nodes, C(1) and D(1), are merged into an internal node with frequency 2. The heap now contains A5, B2, R2, CD2. Next, B2 and R2 are merged into node BR4. Now we have A5, CD2, BR4. The two smallest, CD2 and BR4, merge into CDBR6. Finally, A5 and CDBR6 merge into the root with frequency 11. Assigning 0 to left edges and 1 to right edges, we might generate codes: A=0, B=110, R=111, C=100, D=101. The encoded string becomes 0-110-111-0-100-0-101-0-110-111-0, totaling 23 bits versus 88 bits for 8-bit ASCII — a 74% reduction.

Tracing LZW on "ABABABA"

LZW provides a different walkthrough. Starting with dictionary {A:0, B:1}, we process "ABABABA". w="" + "A" = "A" in dict, so w="A". Next c="B", wc="AB" not in dict, so output code for "A" (0), add "AB" as 2, w="B". Next c="A", wc="BA" not in dict, output code for "B" (1), add "BA" as 3, w="A". Next c="B", wc="AB" is in dict (2), so w="AB". Next c="A", wc="ABA" not in dict, output code for "AB" (2), add "ABA" as 4, w="A". Next c="B", wc="AB" in dict, w="AB". Next c="A", wc="ABA" in dict, w="ABA". End of input, output code for "ABA" (4). Compressed output is [0,1,2,4], demonstrating how longer phrases are captured.

When Compression Fails

If we apply RLE to "abcdef", with no runs, the naive output "a1b1c1d1e1f1" has length 12, doubling the size. This highlights why practical implementations check if compressed length < original length and store the original if not. Similarly, Huffman coding on a string with uniform frequencies, like "abcd" each appearing once, yields codes of length 2 for each character, providing no benefit over fixed 2-bit encoding. Understanding these failure modes is crucial for selecting the right algorithm for the data distribution.

5. Complexity Analysis — Time and Space Complexity

Analyzing the time and space complexity of string compression algorithms is essential for predicting performance on large inputs and for making informed choices in system design. Complexity varies significantly across families due to their differing reliance on sorting, hashing, tree traversal, and dictionary management.

Run-Length Encoding is the most efficient in terms of complexity. It requires a single linear scan of the input, performing O(n) operations where n is the string length, and uses O(1) auxiliary space if implemented in-place or O(n) for the output buffer in the worst case where no compression occurs. Its best, average, and worst cases are all linear because it never backtracks or performs expensive lookups.

Huffman coding is dominated by two phases: frequency counting and tree construction. Counting frequencies is O(n) using a hash map. Building the tree with a heap requires O(k log k) where k is the alphabet size (number of distinct characters), which is bounded by min(n, σ) where σ is the alphabet size, typically 256 for extended ASCII or larger for Unicode. Generating codes via DFS is O(k), and encoding the string is O(n * L) where L is average code length, effectively O(n). Decoding is O(m) where m is the number of bits in the compressed output. Space complexity is O(k) for the tree and code table plus O(n) for output.

Dictionary methods like LZW and LZ77 have more variable complexity. LZW compression processes each character once, with dictionary lookups in O(1) average time using a hash table, leading to O(n) average time. However, dictionary growth can cause increased memory pressure, with space O(d) where d is the number of dictionary entries, potentially O(n) in the worst case for highly varied strings. LZ77's naive implementation with linear search in the sliding window can be O(n * w) where w is window size, but optimized versions using hash tables or suffix trees achieve O(n) average time.

In practice, the alphabet size k is often much smaller than n, so Huffman’s O(k log k) term is negligible for long texts. For LZW, dictionary size is typically capped, for example at 4096 entries for 12-bit codes, to bound memory usage and prevent unbounded growth. This capping introduces a trade-off between compression ratio and memory efficiency, and requires a dictionary reset or pruning strategy when the limit is reached.

6. Variations and Optimizations — Common Improvements and Variants

Basic string compression algorithms serve as building blocks, but production systems employ numerous variations and optimizations to improve compression ratio, speed, and adaptability to different data types.

Adaptive Huffman Coding eliminates the need for a preliminary frequency scan by updating the Huffman tree dynamically as characters are processed. Both encoder and decoder start with the same initial tree and update it identically after each symbol, ensuring synchronization without transmitting the code table. This is advantageous for streaming data where the full input is not known in advance, though it adds computational overhead per symbol.

For RLE, common optimizations include delta encoding for numeric strings, where differences between consecutive values are encoded rather than raw values, and PackBits, which uses a signed count byte to distinguish runs from literal sequences. Another improvement is to use variable-length integer encoding for counts, such as Elias gamma codes, to efficiently handle very long runs without requiring multiple bytes for small counts.

In the Lempel-Ziv family, LZ77 has evolved into LZSS, which improves compression by distinguishing between literals and references with a flag bit, avoiding the wasteful encoding of zero-length matches. LZMA combines LZ77 with range encoding, a form of arithmetic coding that provides better entropy coding than Huffman, and uses large dictionaries up to several megabytes. The DEFLATE algorithm, used in gzip and PNG, combines LZ77 with Huffman coding in two stages: first finding duplicate strings, then Huffman-encoding the literals and length-distance pairs.

Burrows-Wheeler and Modern Advances

The Burrows-Wheeler Transform followed by Move-to-Front and Huffman coding, as used in bzip2, achieves higher compression ratios on natural language by clustering similar characters. More recently, Asymmetric Numeral Systems (ANS), used in Zstandard (zstd) and LZFSE, provide near-optimal entropy coding with faster performance than Huffman or arithmetic coding, offering tunable trade-offs between speed and ratio.

Practical Optimization Tips

Optimizations also focus on implementation details: using byte arrays instead of strings, employing memory views to avoid copying, leveraging SIMD instructions for fast scanning, and choosing appropriate window sizes. For example, increasing LZ77 window size from 32KB to 1MB can improve ratio on large files but increases memory and search time. Profiling with representative data is essential to select the right balance.

7. Real-World Applications — Where This Is Used in Practice

String compression algorithms are ubiquitous in modern infrastructure, often operating invisibly to provide performance and cost benefits across web servers, databases, and networks.

Web servers and browsers rely heavily on HTTP compression. When a client sends an Accept-Encoding header with values like gzip, deflate, or br (Brotli), the server compresses textual responses — HTML, CSS, JavaScript, and JSON — before transmission. This can reduce payload size by 60-80%, dramatically improving page load times, especially on mobile networks. Content Delivery Networks (CDNs) cache compressed assets at edge locations to further reduce latency. Brotli, which combines LZ77, Huffman coding, and a static dictionary of common web strings, typically achieves 15-25% better compression than gzip for web content.

Databases use string compression to reduce storage footprint and I/O. Columnar stores like Apache Parquet and ORC apply RLE and dictionary encoding to string columns with low cardinality, such as country codes or status fields, achieving order-of-magnitude savings. Row-based systems like MySQL InnoDB and PostgreSQL TOAST compress large text fields and overflow pages. In-memory databases like Redis use LZF or zstd to compress values, allowing more data to fit in RAM.

Network protocols compress headers and payloads to conserve bandwidth. HTTP/2 and HTTP/3 use HPACK and QPACK to compress headers via Huffman coding and indexed dictionaries, reducing overhead for many small requests. In messaging systems like Kafka and gRPC, batch compression with zstd or Snappy reduces network transfer and disk usage for log streams. Mobile networks and IoT devices, where bandwidth is constrained, often use lightweight RLE or delta compression for telemetry strings.

Beyond these, string compression is critical in file formats: PNG uses DEFLATE for image data, PDF compresses text streams, and office documents (docx, xlsx) are ZIP archives containing compressed XML strings. Understanding these applications helps engineers choose the right algorithm based on whether speed, ratio, or memory is the priority.

8. Comparison with Alternatives — USE A TABLE to Compare with Related Approaches

Choosing the right string compression algorithm requires comparing trade-offs in compression ratio, speed, memory usage, and suitability for different data patterns. No single algorithm is optimal for all scenarios, and many systems combine multiple techniques.

Run-Length Encoding excels on data with long runs but fails on random or natural language text. Huffman coding provides optimal prefix coding for known frequencies but does not capture repeated substrings. Dictionary methods like LZW and LZ77 capture repetitions without prior frequency knowledge but require more memory for dictionaries or windows. Arithmetic coding and ANS achieve better entropy efficiency than Huffman by encoding entire messages as a single number, but are more complex to implement.

An alternative to compression is simply using a more efficient representation, such as columnar encoding, binary protocols like Protocol Buffers, or deduplication at the storage layer. However, these are complementary rather than mutually exclusive; for example, Protocol Buffers still benefit from additional compression when transmitted over the network.

In practice, hybrid approaches dominate. DEFLATE’s combination of LZ77 and Huffman is a testament to this: LZ77 removes structural redundancy, while Huffman removes statistical redundancy from the remaining symbols. Modern compressors like zstd further refine this by using larger windows, faster entropy coding, and optional dictionaries trained on sample data to improve compression of small strings, such as JSON API responses, where traditional methods struggle due to insufficient context.

9. Common Mistakes and Best Practices — Pitfalls to Avoid

Implementing string compression algorithms correctly requires attention to subtle pitfalls that can lead to data corruption, poor performance, or security vulnerabilities.

A frequent mistake is failing to handle the case where compression expands data. Many novices assume compressed output is always smaller, but as shown with RLE on "abcdef", naive encoding can double size. Best practice is to always compare compressed length to original length and store the original with a flag indicating whether compression was applied. Similarly, for Huffman coding, forgetting to handle the single-character edge case where the tree has only one leaf leads to empty codes and decoding failures; the fix is to assign a default code like "0" in that scenario.

Another common error is incorrect handling of multi-digit counts in RLE or improper dictionary synchronization in LZW. In RLE decompression, parsing "a12" as "a1" followed by "2" instead of "a" repeated 12 times corrupts data. In LZW, the decoder must handle the special case where the code refers to an entry not yet added to its dictionary, which occurs with patterns like "KwKwK". Failing to implement this edge case causes decompression to fail on valid inputs.

Performance pitfalls include using string concatenation in a loop, which creates O(n²) behavior in Python due to immutable strings, instead of using list joins or bytearray. Using inefficient data structures, such as linear search for LZ77 window matching instead of hash tables, can also degrade performance from O(n) to O(n*w). Additionally, not capping dictionary size in LZW leads to unbounded memory growth and eventual out-of-memory errors on large inputs.

Best Practices

Follow these best practices: always operate on bytes for real systems to handle arbitrary data and avoid Unicode issues; include checksums or magic headers to detect corruption; benchmark with representative data rather than synthetic worst cases; and consider using well-tested libraries like zlib, brotli, or zstandard for production instead of custom implementations, unless learning or platform constraints require it. When implementing for interviews, clarify whether compression should be in-place, whether counts should be omitted for single characters, and how to handle empty or None inputs. Finally, ensure decompression is thoroughly tested with round-trip property tests: decompress(compress(s)) == s for all valid s.

10. Interview Questions — 3-5 Common Interview Questions About This Topic

String compression is a popular interview topic because it tests understanding of strings, hash maps, heaps, and two-pointer techniques. Below are common questions with high-level approaches.

Q1: String Compression (LeetCode 443) — In-Place RLE

Problem: Given an array of characters chars, compress it in-place such that consecutive duplicates are replaced by the character followed by the count. If count is 1, omit it. Return the new length. Must use O(1) extra space.
Approach: Use two pointers: read pointer to scan runs and write pointer to overwrite the array. Count each run, write the character, then write count digits if count > 1. Time O(n), Space O(1). Be careful to convert counts to string digits individually and handle multi-digit counts like 12.

Q2: Design Huffman Coding — Encode and Decode

Problem: Implement Huffman encoding and decoding given a string. Build the tree, generate codes, encode, and decode.
Approach: Steps: 1) Count frequencies with Counter, 2) Build min-heap of nodes, 3) Repeatedly merge two smallest nodes until one root remains, 4) DFS to generate codes, 5) Encode by concatenating codes, 6) Decode by traversing tree per bit. Discuss O(n + k log k) time and O(k) space. Follow-up: how to handle decoding without storing tree? Answer: transmit frequency table or code lengths.

Q3: Valid Compressed String / Decompression Check

Problem: Given a compressed string like "a3b2c1" and an original string, determine if the compressed form is valid or decompress it. Alternatively, given "a2b2c3", count decompressed length without actually decompressing.
Approach: Parse the compressed string by reading character then accumulating digits. For validation, decompress conceptually and compare lengths or characters without building huge output if length is large. Use two pointers if comparing compressed vs original directly. Edge cases: invalid formats like "3a" or "a0".

Q4: LZW Compression — Implement Compress/Decompress

Problem: Implement LZW compression that takes a string and returns list of integer codes, and decompression that reverses it.
Approach: For compression, initialize dictionary with 256 single-byte entries, iterate through input building longest prefix w in dictionary, output code for w and add w + next char to dictionary. For decompression, rebuild dictionary in sync, handling the KwKwK edge case where code equals dict_size. Emphasize dictionary synchronization and capping size. Time O(n) average with hash map.

Q5: Compare Compression Ratios — Choose Best Algorithm

Problem: Given a dataset description, e.g., "log file with many repeated timestamps" vs "natural English text" vs "DNA sequence ACGT repeats", which compression algorithm would you choose and why?
Approach: Demonstrate system design thinking: For logs with repeated substrings, choose LZ77/DEFLATE or dictionary method; for skewed frequencies like DNA with 4 symbols, Huffman or 2-bit encoding; for bitmap-like runs, RLE. Discuss trade-offs in ratio vs speed vs memory, and mention hybrid like DEFLATE for general text. This tests ability to map algorithm properties to real-world data characteristics rather than just coding.

Preparing for these questions involves not only coding the algorithms but also articulating complexity, edge cases, and when each technique is appropriate. Practice implementing each from scratch without library helpers for Huffman trees and LZW dictionaries to build fluency.