Challenge 3: Reading a Profiler Result — Solution

// The fix: wrap parseAndSortLargeList() in remember(...), using whatever
// value it's actually computed from as the remember key, exactly as
// Chapter 1 demonstrated:
//
// val sortedList = remember(rawItems) { parseAndSortLargeList(rawItems) }
//
// This ensures the expensive parse-and-sort work only re-runs when
// "rawItems" itself genuinely changes, instead of on every single
// recomposition regardless of whether the underlying data changed at
// all.

// Why profiling — not guessing — correctly identified this:
//
// The CPU Profiler's trace showed 85% of the screen's load time was
// concretely spent inside this ONE function — a measured fact, not a
// hunch about "this code looks slow." Without that measurement, a
// developer might have reasonably (but wrongly) suspected the network
// call, the Room query, or the Compose rendering itself as the
// bottleneck, and spent time optimizing something that wasn't actually
// the problem. The profiler pointed at the exact function consuming the
// vast majority of the time, which is precisely what let the fix be
// targeted (add remember around THIS specific function) rather than a
// broad, unfocused sweep of "add remember everywhere just in case" —
// exactly the "profile first, then fix what it points at" principle
// from the start of this chapter.

Notes:
- This scenario deliberately reuses Chapter 1's exact remember(items) { }
  pattern — the point of this challenge is recognizing that a profiling
  result should lead back to a technique already learned, not require
  discovering something entirely new.
- 85% concentrated in one function is also a strong signal that fixing
  ONLY this one spot will produce a large, measurable improvement — a
  profiler showing time spread evenly across dozens of small functions
  would instead suggest no single fix would move the needle much, a
  genuinely different situation calling for a different strategy.