Advanced Computer Systems & Architecture · UTM showcase
Pressing Run sends one job to a Rust service. That single job takes memory, splits the work across the runtime, consults a cache, is driven asynchronously, writes its result down and then gives the memory back. Every number below is read from the running process — the allocator counts its own bytes — not calculated in the browser.
Run the same settings twice: the second is a cache hit and never allocates.
The buffer is requested in one piece with a known size, so the request does not grow into repeated reallocations. The figures are the allocator's own, taken before the allocation and again after it.
Each slice of the buffer is summed at the same time on the runtime's thread pool. The thread named against each slice is the one that actually ran it, so raising the worker count visibly spreads the work.
Run the pipeline to see the split.
A map sits in front of the expensive path, keyed by the whole request. On a hit the buffer is never allocated and no worker runs, which is why the elapsed time collapses.
The request returns a job id straight away and the work carries on afterwards. The poll count is how many times the browser asked before the answer existed — proof the connection was never held open waiting.
Every completed job is written to SQLite before the process forgets it. The cache and the job map die with a restart; these totals do not.
Rust has no garbage collector. A value is freed the moment it leaves scope, at a point you can name in the source — here, an explicit drop. The released figure is the difference in the allocator's live count across that one line.