Loading today’s stories
Build1 distinct publisher3 min readPublished
The absolute numbers describe an i5 in Docker with about 8 GB available, and the author says the relations between the profiles are hypotheses for you to retest rather than results any other service can inherit.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
Console JSON is a schema: .NET 10 dropped the duplicate State.Message, and parsers go quiet1 distinct publisher
build
MTP 2.3 writes TRX as tests finish, so a dead test host no longer erases the evidence1 distinct publisher
build
.NET 10 fails restore on a versionless PackageReference, and the reflexive fix breaks CPM1 distinct publisher
build
VlvRequestControl throws on the malformed target that .NET 9 used to rewrite1 distinct publisher
Each of the four profiles changes the shape of the thing you operate, not only its speed. A framework-dependent JIT application can share the installed runtime with other processes on the host [4]. A self-contained JIT publish gives that up in exchange for operational isolation [5]. ReadyToRun brings part of the compilation forward while keeping the dynamic runtime [3]. Native AOT removes the in-process JIT altogether, which is where the reduction in time to first response comes from [2]. The four profiles amount to four systems to run [1].
The list of metrics that can decide the project runs to ten: startup, warmed throughput, p95, p99, CPU, resident memory, distribution size, update frequency, dynamic-code compatibility and publish time [6]. Four profiles against ten metrics is a 40-cell matrix [1], and a label such as "CLI" or "serverless" is an attempt to fill it in from the row header [7]. The rule the author lands on is stricter than the usual advice: state a goal, choose the metrics capable of refuting it, and compare equivalent distributions, measuring fresh processes for first response, RSS under representative load for density, and tail latency and CPU alongside RPS for throughput [13].
The measurement boundary is what decides the serverless argument. Startup here is the interval from starting a process to a valid response from /ready, with the filesystem cache already warm [9]. A managed cold start also contains provider decisions, sandbox creation, image pull, network and configuration, and the author states he did not measure that path and so does not credit Native AOT with a universal serverless gain [10]. That restraint runs through the rest of the piece.
Predictability gets the same discipline. Removing the JIT stops methods being compiled during execution; it leaves GC pauses, OS scheduling, contention, I/O and page faults exactly where they were [11]. Source generators move discovery to build time and push errors into the build, without making any architecture faster by themselves [12]. The lab also keeps managed allocation and resident set size as separate questions [17], which matters because density is charged in RSS and allocation counters do not report it.
Transfer depends on conditions that are stated plainly. The harness is Ubuntu 24.04 under Docker Desktop on an Intel Core i5-1245U with roughly 8 GB available, SDK 10.0.400 and runtime 10.0.11; every profile runs in Release, in the Production environment, with no logging providers and the same payload, and the measured code touches no database, no disk and no external service [14]. The workload is fixed at Seed=42, ItemCount=2048 and Iterations=8 [18]. So the figures describe a CPU-and-allocation-bound path on a mobile-class chip inside a desktop container runtime. Put a database call in the request path, enable a logging provider, or run the host under memory pressure, and the JIT-versus-AOT term stops dominating. The author's own framing agrees: the absolute values belong to that workload, that hardware and that environment, and the relations between profiles are hypotheses for the reader to test [15].
Ranked by verification strength, evidence, and original report placement.
There is no universal winner in the comparison between .NET Native AOT, JIT and ReadyToRun; each publish model optimises a different part of the system.
Native AOT eliminates the JIT at execution time and greatly reduces time to first response.
ReadyToRun brings forward part of the compilation without abandoning the dynamic runtime.
A framework-dependent JIT application can share the installed runtime with other processes.
A self-contained JIT publish prioritises operational isolation.
The article lists metrics that can decide the project: startup time, warmed throughput, p95 and p99, CPU, resident memory, distribution size, update frequency, compatibility with dynamic code, and publish time.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 4, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Legible method, single witness
The procedure is more transparent than most vendor benchmarks: exact SDK and runtime builds, a fixed seed, thirty randomised launches per profile, separate containers for load generator and application, and an admission that a Windows bind mount was corrupting early startup numbers. What it does not have is a second pair of hands. The author holds the CSVs, ran the only machine, and is the only source in this story, so the reproducibility is designed rather than demonstrated.
One laptop, one afternoon
Nothing in this reporting shows the practice or the profiles in use anywhere beyond the author's container. There is no production deployment, no fleet, no third party who adopted the matrix and reported back — the entire footprint is a single i5 with roughly 8 GB available, running Release builds against a /ready endpoint that touches no database, disk or network service.
The author talks himself down
The direction here is unusual: the framing is more conservative than the material would license. The most quotable possible headline — Native AOT wins serverless — is the one the author explicitly refuses, on the grounds that he timed a /ready probe rather than a provider cold start with sandbox creation and image pull. He also demotes his between-profile relations to hypotheses and reminds readers that removing the JIT leaves GC and scheduling exactly where they were. A single-laptop lab still cannot carry general conclusions, which is why this sits just below neutral rather than far below.
Series momentum, no sponsor in sight
This is part two of a self-published series, written partly in response to a technical argument about part one, on a platform where series continuity and audience are the currency. That is a mild pull toward a striking result and toward validating the earlier guide — and the author's chosen framing of "my revised rule" carries a reputational stake. Set against that: no vendor, product, sponsorship or commercial interest appears anywhere in the material, and the tooling named is all free.
Trust the method, not the magnitudes
We can be fairly confident about what was done and what was claimed, because the setup is spelled out and the limits are stated by the person who knows them best. We can be much less confident that any of the magnitudes survive a move to server-class hardware, arm64, or a workload that touches a database — and with one publisher and one operator, there is no way to catch an error in the harness from here.