Parallel execution profile

Background

Parallel executors are isolated — each starts with an empty transcript, unaware of what the others are fetching. That's safe to run concurrently, but it means two executors can issue the same search and duplicate the retrieval. The lesson's post-mortem quantifies both the speed win and this duplicated work.

Problem statement

Implement parallel_profile(executors) returning timing + duplication stats.

Input

• executors — a list where each element is the list of search queries one executor issued.

Output

Returns a dict with keys:

• "total_searches" — total search calls across all executors,
• "unique_searches" — distinct queries,
• "duplicate_searches" — total - unique,
• "wall_clock_sequential" — sum of per-executor search counts,
• "wall_clock_parallel" — max per-executor search count (0 if empty).

Examples

Example 1 — two executors hit the same query

Input:  executors = [["AlphaCode"], ["AlphaCode"]]
Output: {"total_searches": 2, "unique_searches": 1, "duplicate_searches": 1,
         "wall_clock_sequential": 2, "wall_clock_parallel": 1}

Constraints

• Flatten all executor queries to count total / unique / duplicate.
• wall_clock_sequential = sum(len(e) for e in executors).
• wall_clock_parallel = max(len(e) for e in executors) (or 0).
• Return the five-key dict.

Notes

• duplicate_searches > 0 is the isolation tax — exactly what a shared memory layer (next lesson) eliminates.