WEBVTT

1
00:00:00.000 --> 00:00:08.167
This overview explains how preparation, kernel execution,
wrappers, and delivery contribute to a completed request.

2
00:00:08.167 --> 00:00:14.467
A faster kernel can belong to a slower overall
path when costs outside the timer are omitted.

3
00:00:14.767 --> 00:00:17.300
Use abstract cost units.

4
00:00:17.300 --> 00:00:22.300
A request takes one unit to parse, eight to prepare, one to execute, and

5
00:00:22.300 --> 00:00:24.467
two to deliver its output.

6
00:00:24.467 --> 00:00:26.767
The complete total is twelve.

7
00:00:26.767 --> 00:00:32.933
The numbers are a worked accounting example, not a measurement from the research results.

8
00:00:32.933 --> 00:00:36.167
An execution-only timer reports one.

9
00:00:36.167 --> 00:00:40.633
A timer including preparation and execution reports nine.

10
00:00:40.633 --> 00:00:43.367
The complete request reports twelve.

11
00:00:43.367 --> 00:00:47.533
These numbers can all be correct while answering different questions.

12
00:00:47.533 --> 00:00:53.500
A ratio is uninterpretable unless both methods use the same boundary.

13
00:00:53.500 --> 00:00:58.800
For a control with costs one, two, three, and two, the full total is eight.

14
00:00:58.800 --> 00:01:03.900
The candidate wins the execution-only comparison, one against three, but loses the

15
00:01:03.900 --> 00:01:06.967
complete request, twelve against eight.

16
00:01:06.967 --> 00:01:12.200
No contradiction exists once the boundaries are visible.

17
00:01:12.200 --> 00:01:12.201
A completed request runs from source
preparation through delivery of the answer.

18
00:01:12.201 --> 00:01:17.433
A completed request runs from source
preparation through delivery of the answer.

19
00:01:17.433 --> 00:01:25.167
Compilation prepares an artifact; the kernel evaluates
it; wrappers, extraction and delivery add other work.

20
00:01:25.167 --> 00:01:32.500
These timer brackets specify which costs are counted:
preparation, the kernel, or the complete request.

21
00:01:32.500 --> 00:01:37.633
The following costs are invented teaching
values, not benchmark measurements.

22
00:01:37.633 --> 00:01:42.667
Method M takes 8 milliseconds to prepare and 1 per evaluation.

23
00:01:42.667 --> 00:01:46.933
Method C takes 2 to prepare and 2 per evaluation.

24
00:01:46.933 --> 00:01:53.000
One completed request takes 9 for M and 4
for C, even though M's kernel is faster.

25
00:01:53.000 --> 00:01:58.833
With 10 evaluations and preparation
charged once, the totals become 18 and 22.

26
00:01:58.833 --> 00:02:02.400
Those totals describe only this toy lifecycle.

27
00:02:02.400 --> 00:02:11.400
Cold construction, a warm resident artifact, retained state across
queries and reload in a new process each impose different obligations.

28
00:02:11.400 --> 00:02:16.867
Complete vectors, scalar counts and projected
counts also need separate endpoints.

29
00:02:16.867 --> 00:02:20.567
Later retained measurements carry their own boundaries.

30
00:02:20.875 --> 00:02:25.093
Return to the opening four-stage ledger, using abstract cost units.

31
00:02:25.093 --> 00:02:32.143
Candidate parsing costs one, preparation eight, execution one per use, and delivery two per use.

32
00:02:32.143 --> 00:02:36.430
The control costs one, two, three and two respectively.

33
00:02:36.430 --> 00:02:46.232
With one prepared object and ten uses, the totals are one plus eight plus ten times three, or thirty-nine, and one plus two plus ten times five, or fifty-three.

34
00:02:46.232 --> 00:02:52.026
These costs differ from the intervening eighteen-versus-twenty-two example.

35
00:02:52.776 --> 00:02:57.690
Ten independent cold requests cost one hundred twenty and eighty instead.

36
00:02:57.690 --> 00:03:00.758
The reuse assumptions changed the answer.

37
00:03:00.758 --> 00:03:07.359
Calling both experiments ten runs without describing object lifetime would hide the reason for the difference.

38
00:03:08.109 --> 00:03:12.826
Report the output contract, residency, and timer boundary together.

39
00:03:12.826 --> 00:03:21.418
Repeated measurement does not itself imply reuse, and reuse does not imply that output delivery has disappeared.

40
00:03:21.418 --> 00:03:21.423
delivery has disappeared.

41
00:03:21.423 --> 00:03:25.523
State exactly where the timer starts and stops.

42
00:03:25.523 --> 00:03:33.056
Compare identical delivered outputs under
the same cold, warm, resident, or reload lifecycle.