Why does my PerryTS project take so long to compile?

[deepdark-max]

I tried compiling this most basic code:

import { App, VStack, Text, Button, State } from "perry/ui"

const count = State(0)

App({
    title: "Counter",
    width: 800,
    height: 600,
    body: VStack(16, [
        Text(`Count: ${count.value}`),
        Button("Increment", () => count.set(count.value + 1)),
    ]),
});

It's only 13 lines of code, but running perry run took:

Measure-Command { perry run src/main.ts } 2>&1 | Select-Object TotalSeconds

TotalSeconds
------------
  27.7677348

My CPU is an i5-12100. Is this a problem on my end?

[proggeramlug]

Hi! Short answer: this is expected for a first build, and almost certainly not a problem with your setup.

The key thing is that Perry isn't an interpreter or a TS-to-JS transpiler — it's an ahead-of-time native compiler. Those 13 lines don't run as 13 lines; they go through the full pipeline:

TypeScript → parse (SWC) → HIR → LLVM codegen → .o → link (cc) → native .exe

Almost none of your 27.7s is spent on your source. The work that actually scales with "13 lines" is tiny — on my machine, compiling+linking your exact counter program is ~2 seconds. The rest is fixed cost: LLVM optimization, linking against the native UI runtime, and (the big one on a first run) Perry's auto-optimizer producing an optimized build. That cost barely changes whether your file is 13 lines or 1,300, and a perry/ui app is on the heavier end because it links the full native GUI layer.

The part that matters: that cost is mostly one-time. Perry caches compiled objects keyed by your source hash, so a second perry run with no source change should be dramatically faster — it reuses the cache instead of recompiling:

# First run – full compile + optimized link
Measure-Command { perry run src/main.ts }   # ~27s for you

# Second run, no source change – should be a fraction of that
Measure-Command { perry run src/main.ts }

Could you post the timing of that second run? That's the deciding test:

• If the second run is much faster → everything is working as intended, and the 27.7s was a normal one-time cost. 👍
• If the second run is also ~27s every single time → the cache/optimizer isn't being reused on your machine, and that would be worth digging into as a real issue (let us know your Perry version + OS and we'll take a look).

A few notes:

• Editing the file changes its hash, so the next run recompiles — that's expected.
• ~25–30s for a cold native + GUI build on an i5-12100 is in the normal range. Native AOT trades a slow first build for a fast standalone binary with no runtime/VM.

TL;DR: cold native+UI builds taking ~half a minute is normal; warm re-runs should be fast. Post that second-run number and we'll confirm. 👍

[deepdark-max]

I tested this with the help of AI.

Here are my current symptoms:

1. Regardless of cold compilation or cache hits, perry compile always takes around 28 seconds. The same applies when using --no-link.
2. The compilation pipeline (parsing, transformation, and code generation) completes in just 0.13 seconds, and the cache is being hit correctly.
3. The actual time spent is concentrated in the ~25-second gap between code generation finishing and linking starting. During this period, perry.exe barely consumes any CPU.
4. Both perry binaries (npm 0.5.1167 and WinGet 0.5.1159) exhibit the exact same behavior.
5. The linking stage produces hundreds of duplicate symbol warnings (overlapping between perry_ui_windows.lib and perry_runtime.lib).

Could you please help me troubleshoot this issue? Thanks!

[deepdark-max]

PS J:\perryts> perry doctor
Perry Doctor

Environment Checks
──────────────────
[OK] perry version: 0.5.1167
[OK] update status: up to date
[OK] clang (LLVM codegen): clang version 22.1.7 (https://github.com/llvm/llvm-project a255c1ed36a1d06f79bd2633ba9f8d900153007c)
[OK] system linker (lld-link + xwin sysroot): C:\Program Files\LLVM\bin\lld-link.exe + C:\Users\xiake\AppData\Local\perry\windows-sdk
[OK] runtime library: C:\Users\xiake\AppData\Local\Microsoft\WinGet\Packages\PerryTS.Perry_Microsoft.Winget.Source_8wekyb3d8bbwe\perry_runtime.lib
[OK] project config (perry.toml): found
[OK] compatibility reports (#849): mode=ask (sent=0, suppressed-by-dedup=0, queued=0, cache=empty)

All checks passed!

[deepdark-max]

Oh, I've figured out the problem. It's because the PERRY_WORKSPACE_ROOT wasn't set properly : )