Choose tasks a reader actually performs
For long documentation, opening time is only one concern. A person may need to jump to a heading, find an exact phrase, follow a link and return to the same place. Decide which of these actions matter before generating a test file. A huge file of repeated identical paragraphs can exercise a parser but may tell little about a real review task.
The rendering corpus checks syntax, not scale. To extend it, create a synthetic document with a fixed seed, count of headings, tables, links and code blocks, then publish the generator or the exact file. Record byte size and line count. Do not reuse a private project document without permission.
Record a fair run
Write down Mac model, macOS version, app version, whether the file is local, and whether the app was already running. Define start and finish for “open.” Repeat the same task several times; note warm and cold runs separately. Capture failures such as a delayed outline or search jumping to the wrong occurrence, not only elapsed time.
For cross-app comparison, use the same file and task in each app. A feature that is absent should be recorded as unavailable for that version, not given an invented time. Avoid claiming an app is “instant” from a short screen recording.
This article publishes a protocol, not performance results. Aero Markdown’s Mac app is not publicly available, and no measured long-file benchmark is presented here. The Markdown workflow comparison likewise separates documented features from hands-on testing. If we later publish measurements, they should live with dated files and results on this page.