Romaji to Kana Converter: React & Next.js — Chapter 6, Exercise 1
=====================================================================

TASK
Re-run this chapter's own three-way benchmark (file re-scan / in-process
Map / real Redis) at a smaller scale — 5,000 dictionary entries instead
of 50,000 — and explain, using the real numbers you measure, which
method's own timing changes the most and which barely changes at all.

SOLUTION

Running the identical benchmark, only shrinking the dictionary from
50,000 entries down to 5,000, against 200 real lookups:

  Method             50,000 entries   5,000 entries
  -----------------  --------------   --------------
  Naive file re-scan    ~41,800 us/call    3,111.74 us/call
  In-memory Map               ~0.65 us/call        0.12 us/call
  Real Redis GET             ~944 us/call          993.43 us/call

The naive file re-scan changed the most by far -- roughly a 13.4x
speedup for a 10x smaller dictionary, tracking size almost linearly.
That's expected: this method re-reads and re-parses the entire file
and then linearly scans the whole array on every single lookup, so
its own cost is directly proportional to how many entries are in the
file, regardless of which one is actually being searched for.

Real Redis GET barely changed at all -- 944us at 50,000 entries versus
993us at 5,000, a difference well within the kind of run-to-run noise
this course has already seen in earlier chapters' own timing
measurements. That's the expected result too: Redis looks a key up by
hashing it directly to its stored value, not by scanning through
every other key in the store, so dictionary size has essentially no
effect on a single GET's own cost. What actually dominates Redis's
per-call time is the real network round trip, which doesn't care how
big the dataset behind it is.

The in-memory Map also shrank, from roughly 0.65us to roughly
0.12us -- but both numbers are already fractions of a single
microsecond, the same "tiny, noisy baseline" territory Chapter 4's
own Exercise 3 already warned about. A change at that scale is
consistent with real measurement noise (build overhead for the
smaller Map, CPU cache effects on a smaller table) more than a
meaningful, structural difference -- the honest takeaway is that both
numbers round to "negligible," not that one Map size is genuinely
5x faster than the other in any way that would matter in practice.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reports the real, re-measured numbers at the smaller scale rather
than assuming they'd shrink proportionally across all three methods,
and correctly explains why only the naive scan's own cost is
genuinely tied to dictionary size -- both Map and Redis lookups are
effectively size-independent, for two different real reasons (Map's
own hash-based lookup, and Redis's own round-trip-dominated cost).