Krate
Measurements you can inspect.
A notes workload compared on the same machine, plus an inventory of application files in this checkout. These are different kinds of evidence: neither establishes a performance result for every Krate app or for the latest release.
Krate notes and MarkText.
MarkText 0.17.1 ARM64 vs the Krate notes replica, Apple M4, macOS 27 (build 26A5388g), on AC power; equivalent-workload comparison, not feature parity. This does not establish full editor feature parity. Warm-open and memory rows refer to the same 50,000-line document, not different document sizes.
| Measurement | Krate | MarkText |
|---|---|---|
| Historical app bundle versus installed application | 36.6 KiB | 284.6 MiB installed |
| Memory, 50,000 lines | 178.5 MiB, one process | 2,299.4 MiB across four processes |
| Warm open, 50,000 lines | 237.1 ms median | 611.5 ms median |
Warm open is time to a visible window, median of ten runs per app. Memory is settled footprint across the whole process tree. The historical app-bundle row excludes Krate's shared runtime and does not measure a current source-bearing bundle.
Lower numbers in these rows are useful evidence for this workload, not a universal efficiency claim. Application features, assets, rendering, host calls and data handling can change the result. Energy was not measured.
The public checkout includes the protocol, analysis, machine summary and seal. It does not distribute every retained raw sample. A seal records file identity, not an independent review. Reproduction requires the documented apps, hardware and measurement setup; generating this website is not reproduction of the experiment.
Bundle, code payload and runtime are different costs.
A .krate bundle contains a WebAssembly component and manifest, and can also carry source, SDK interfaces and assets. Full bundle bytes, uncompressed code payload, runtime download and installed runtime size are different measurements.
The recipient installs a compatible Krate runtime once. Applications use supported Krate APIs; existing desktop binaries do not become portable without adaptation.
27 artifacts in this checkout. Full bundle bytes are the actual archive length; code payload is the uncompressed code.wasm entry. Compression means payload bytes are not an additive part of the archive length. Equal app names on different shelves are retained as different artifacts. Older bundles without source do not establish the size of a newly packed, source-bearing app.
Runtime size varies by release, platform and packaging. Use the published release assets for download sizes; measure installed size separately. No game-versus-editor or game-versus-chat-client size ratio is used here.
How to evaluate your application.
- Choose equivalent user tasks and verify their outputs before timing.
- Record machine, OS, architecture, app and runtime versions, input digests, dependencies and permission settings.
- Separate full bundle, code payload, runtime download and installed footprint. Include the shared runtime when evaluating first install.
- Measure cold and warm runs separately. Retain samples, process-tree accounting and failure cases rather than reporting only the best run.
- Publish limits and reproduction steps beside any headline ratio.
Repository inventory is not proof of current release compatibility. Consult the inventory and test links, current limits and the porting guide before choosing a workload.