Walk the first real experiment through the whole lifecycle - #121
Merged
Conversation
The plan reaches a first release built on machinery no experiment has ever used. Machinery that has never carried a real load is a design, and the cheapest place to find out that the record format is annoying or that a check fires on legitimate work is the first experiment rather than the tenth. This is the question, committed before any of its code exists, which is the ordering this board is built on. The answer is genuinely unknown: the runner opens every record it finds, and whether that or the walk itself is where the time goes decides whether the size bound on a record is the interesting number or the directory count is. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
The prototype for the question this experiment asks. It writes a thousand records into a temporary directory, times a pass that asks the filesystem about each one against a pass that opens each one, and removes the tree. It is not run by any check and nothing in the runner imports it, which is record 0009 and record 0002 respectively. The comparison is between asking and reading rather than between walking and doing nothing, because asking is what the runner does before it decides whether a record is inside the size bound, and a pass that did nothing would measure the loop. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
Yes, and by about three times on the machine it ran on. The numbers, the command that produced them and the platform are in the record, together with what the measurement does not say: one machine, one filesystem, and a tree fifty times the size of this repository's own, so the whole thing is milliseconds either way. The state moves to answered and the answer date is added, which is the second half of the lifecycle this experiment exists to walk. What the walk cost as an experience goes in #40 rather than in the record, because the record is about the question it asked. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #40
What this changes
The first experiment, walked through the whole lifecycle in the order the
lifecycle asks for. Three commits: the question, then the code, then the answer.
experiments/reading-a-tree-of-records/asks whether opening every record on atree of a thousand costs more than asking the filesystem about them without
opening them. The answer is yes, by about three times on the machine it ran on,
and the record carries the numbers, the command that produced them, the platform
and what the measurement does not say.
The question was chosen because its answer was genuinely unknown rather than
because it suited the tooling. A directory walk that opens each directory in
turn is not obviously cheaper than reading a kilobyte out of a file the walk has
already found, and on a filesystem with a slower directory layer it may not be.
What failure it prevents
Machinery that has never carried a real load is a design. Everything in the plan
up to here is built for experiments that do not exist, and the cheapest place to
find out that the record format is annoying or that a check fires on legitimate
work is the first experiment rather than the tenth.
What was run
At the commit being pushed,
e433a3853fe4b6e78fa79b60e9ba33fda1e26eb0.The record was accepted from the first commit, in state
askingwith an emptyanswer section, and the listing showed it waiting nought days before the code
existed. That ordering is the thing this board is built on and it is worth
saying that nothing got in the way of it.
What this does not do
The measurement is about one machine, one filesystem and one platform. A tree of
a thousand records is fifty times the size of this repository's own tree today,
so the whole thing is milliseconds either way and none of it is a reason to
change anything. What it settles is which of the two numbers is worth watching
if a walk ever does get slow.
The prototype is not run by any check and nothing in the runner imports it. It
is compiled by
go build ./...and read bygo vet ./...like everything elsein the module, which is one of the things the walk found and which has its own
issue rather than a repair here.
What the walk cost as an experience, and the follow-up issues it produced, are
written into #40 rather than into the record. The record is about the question
it asked.
No second reader tonight. The transcript above is in place of one, and every
number in it carries the command that produced it.