[SanderMuller]

save() writes the packageDependencies section of the result cache without sorting it. The section follows the order in which the workers finish, so two runs of the same project write different files.

With the sort, two cold runs of a 4524-file project wrote files that differ only in lastFullAnalysisTime. Without it they differed in 615894 bytes. The file can then be compared with diff -a or with a content hash. The sort costs about 0.5 ms per save on that project. I measured these numbers on 2.3.x in September.

The packages of one file get a sort too, because they come in the order in which the file's dependencies are found.

e2e/result-cache-deterministic-order fails without either sort.

🤖 Generated with Claude Code

[staabm]

I am not sure its worth sorting the results or whether a diff/debug-tool should do it before comparing

[SanderMuller]

Good question, and it made me go and check which of the reasons actually survive. One of the three I had in mind does not, so here they are with numbers. Two cold runs of the same 4524-file project, 75.3 MB cache, same size every time.

Diffing, which is your point. You are right that a tool could canonicalise first. Worth knowing that plain diff already refuses the framed format from 2.2.13 (Binary files ... differ, about 25k NUL bytes per MB), so this is diff -a territory either way:

diff -a run1 run2 | grep -c '^[<>]'
2.2.x        3932
with sort       2

That is Ondřej's pro-tip from your 2023 post, diffing the cache to find out why it was not reused. It works today, in any shell, without a tool existing. A tool that sorts first would work too, it just has to be written first and then parse every frame and know which sections are order-insensitive.

Content hashing, which a tool cannot retrofit cheaply. Without the sort you cannot content-address the file at all. With it, two runs are identical apart from lastFullAnalysisTime, so a consumer reads that frame's header for its length, skips it and hashes the rest. Ten lines, no further knowledge of the format. I checked both directions: skipping the timestamp, 2.2.x hashes differ and the sorted ones are equal.

Deduplication, which I had in the description and which does not hold up. I measured what an incremental store or transfer would actually rewrite between two runs, and the ordering churn is localised:

              4K blocks   64K blocks
2.2.x         129/18381    10/1149     ~0.5 MB of 75 MB
with sort       1/18381     1/1149     ~0.1 MB

So about half a megabyte per run. Not worth carrying code for, and I will drop that claim from the description.

Cost of the sort, on the real array from that project (4524 files, 2792 package names): median 0.454 ms as it comes out of the run, 0.861 ms if I shuffle it first as a worst case, against a cold run of about 30 s.

So the case is the diff line count and the hashability, not storage. If neither is worth 0.5 ms to you and Ondřej, I am happy to close it, that is a fair reading of the same numbers.

Separately, the description said there was no e2e fixture, which is out of date since I pushed one. Updating it now.

[ondrejmirtes]

This comment is verbose and totally unnecessary

[SanderMuller]

Removed. I also shortened the comments in the e2e fixture.