HTML Architect: Performance Regression Tests in CI/CD

DanilTkachenko · September 1, 2026, 5:06pm

Performance Regression Tests

In the future, once Origam HTML Architect show good numbers, become stable, and users start settling in, it would be good to start thinking about Performance Regression Tests in CI/CD.

Right now we have a problem where HTML Architect uses a lot of memory and sometimes a lot of CPU when loading a model:

This could be fixed in a couple of PRs, but inevitably, a few months after we fix it, performance will start to degrade again.

In the future, I think it would be a good idea to build CI/CD pipelines that run, for example, every day or before every release, and report the current statistics on our performance.

ASP.NET has something like this:

github.com/aspnet/Benchmarks

build/benchmarks-ci-01.yml

main

# Do not change this file, it is generated by the pod-scheduler.
# Source of truth: see ../scripts/pod-scheduler/README.md
# To regenerate, run from the repo root:
#   python ./scripts/pod-scheduler/main.py --config ./build/benchmarks_ci_pods.json --base-name benchmarks-ci --yaml-output ./build

trigger: none
pr: none

schedules:
- cron: "0 3/12 * * *"
  always: true
  branches:
    include:
    - main

variables:
  - template: job-variables.yml
  - name: session
    value: $(Build.BuildNumber)
  - name: buildId

This file has been truncated. show original

The same approach have MongoDB

An interesting point is that they don’t run these pipelines on every PR, only on a schedule. This is because of the huge number of PRs they get hundreds of PRs every day, and their machines can’t process hundreds of commits without a big delay. At the same time, this also solved the problem of noise in CI/CD by this

Here’s an article that touches on this topic of Performance Regression Tests in CI/CD:

DanilTkachenko · September 1, 2026, 5:15pm

Also, I once talked to Microsoft developers in person they write tests for absolutely everything, it’s practically tests on top of tests over there. I think there’s something useful we could take from that, or at least I hope I’m not exaggerating here. Postgres maintainers have a similar philosophy too, just modified in some ways