Skip to content

Record allocation benchmark diagrams ​

Record allocation benchmark

Start with how the application begins, then follow data between its folders. Open an operation to see its decisions, calls, failures and cleanup. Its explanation supplies the exact contract and linked dependencies.

This view includes 2 application source files. Package and interface boundaries show checked contracts; their runtime implementations are not expanded. The views describe the checked program, not desired requirements or a recorded execution.

Where execution begins ​

Startup ​

It sets iterations to 50000. It stores a list with no items in owned values (List<Item>). It sets index to 0. While index is less than iterations, it appends an Item with id from index and name "August" to values; then it increases index by 1. source

After the loop, it sets checksum to 0. For each item in a snapshot of values, it increases checksum by item.id. After the loop, it prints checksum. source

Data flow ​

No calls cross the source files in this view. Follow local operations in the file sequences below.

Follow the data ​

Each row opens the complete operations and call sites behind one pair of logical units. A grouped arrow records calls between those units; connected arrows need not belong to the same execution path.

FromToOperationsRead
Startupdata1Inputs, results and call sites

Data crossing these boundaries (1 contracts) ​

Startup → data ​

1 operation, 1 site

Item · value construction

Inputs: id: int, name: string. Result: Item.

Caller or entryEvidence
StartupCall site · Caller explanation

Open a module ​

ModuleRead
data.augFlow and sequences · Explanation
main.augFlow and sequences · Explanation

These are static call boundaries, not a request trace. Interface implementations and foreign internals stop at their checked contracts. Dotted arrows defer a callback or browser action. Imports alone do not imply a call.

Last updated:

The world runs on language