Why Akileas Is So Fast — Akileas Manual

2.1 A keystroke, shown immediately

Inside the editor, "you pressed a key" is split into two halves: show it at once and refine it afterwards. The first does the bare minimum, so the screen is guaranteed to refresh within the same frame. The second is more involved, but it can take its time and can be interrupted at any moment by newer input.

What happens on a single keystroke

Happens immediately

It has to finish within the same frame, or you would see a delay.

You type a character at the cursor
Only that one line is redrawn
The screen refreshes, with the character and cursor in place

Happens afterwards

It runs in the background and never blocks your typing.

The editor starts analysing how the document changed
Only the affected part is recomputed
Syntax highlighting and fine typesetting are filled in smoothly
If you have kept typing, out-of-date results are discarded automatically

This is why typing in a hundred-thousand-line document feels almost the same as typing on a blank sheet of paper. In measured tests, the step from keypress to refreshed screen takes just 37 microseconds — less than one hundredth of a single frame's budget (8.33 ms).

2.2 Only the line you changed is recomputed

Documents usually get sluggish as they grow because every keystroke re-reads the whole thing from scratch. Akileas does not do that.

It reads a document on two levels: one records which parts are paragraphs, headings, code blocks and lists, and the other records the bold text, links and formulas inside a given block. When you change a few words in the body text, the outer structure has not changed at all, so only the line you are editing has to be re-read, while the other 99,999 lines are reused exactly as they were.

NOTE

This is also why typing ordinary text feels like it has no delay at all, and why only something like typing # — which changes the heading structure and pulls a whole block along with it — costs the background a little extra time. Even then, the screen has already finished updating within 85 microseconds, so you never notice the background working.

2.3 Formulas, diagrams and tables that do not hold each other back

Mathematical formulas, Mermaid diagrams and tables are the three most "expensive" kinds of content in a document. If they all shared a single update path, every character you typed could trigger a diagram to be recomputed, and your typing would come out in stutters.

Akileas keeps them independent: only the kind that actually changed is recomputed. Typing in the body text never disturbs the architecture diagram already drawn beside it.

Three independent render paths

The document changes

Mathematical formulas

Re-laid out only after you stop typing
Formulas already computed are remembered
Not recomputed at all while the cursor is elsewhere

Mermaid diagrams

Only diagrams visible in the viewport are compiled
Zooming and panning do not recompute the drawing
Diagram geometry is cached and reused

Tables

Column widths adapt to the actual display width
Text mixing Chinese and English still lines up
Editing a cell affects only that table

Composited into one image and handed to the GPU to draw

2.4 Instant navigation anywhere in a hundred thousand lines

Dragging the scrollbar through a very long document makes many editors freeze first and then jump. The reason is that they have to add up the height of every line from the top just to work out which line your drag position corresponds to.

Akileas arranges the document's entire height into an index that can be searched quickly. However long the document is, locating a position costs only an amount of work proportional to the logarithm of its length — drag the scrollbar to 85% and it can tell you, within a few microseconds, which line and which character that is. Lines that have not been measured yet are estimated at the average height while you scroll, then refined as you keep dragging, so there is no jumping or jitter.

Time to locateA few microsecondsAlmost independent of document length

Scroll jitterNoneUnmeasured lines are estimated, then refined

2.5 Crashes and power loss will not cost you your work

Saving looks like a single action, but if the power fails halfway through the write, a half-finished file can destroy the perfectly good draft you had. Akileas avoids this by writing a copy first, verifying it, and only then replacing the original in one step.

What actually happens when you save

1 Build the new version Assemble the current content into a complete file
2 Write a temporary copy Write to a temporary file first; the original is untouched at this point
3 Verify integrity Confirm the written data is complete and correct, and force it to disk
4 Replace in one step Swap the copy in for the original atomically, with no half-written state
5 Record it in the time machine Keep a historical version you can compare with and roll back to at any time

On top of that, the editor keeps appending a lightweight, verified record of your edits. Even after a power loss, the next time you open the document it checks and replays that record automatically, handing back the content you had not saved.

2.6 The foundations

These capabilities come from a few fundamental choices — choices that put Akileas on a different road from the outset than editors built on a browser engine.

Compiled natively, with no browser engine inside

The whole application is compiled into native code that calls the system's graphics interfaces directly. No browser engine is embedded, so there is no several-second wait to start up and no several hundred megabytes of memory consumed.

No garbage-collection pauses

The compiler decides at compile time when memory is released, so there is no garbage collection while the app runs. The dropped frames that stutter every few seconds simply do not happen here.

Drawn directly by the GPU

Glyphs, vector graphics and interface elements are all rendered by the GPU, with support for 120 FPS high-refresh-rate displays and crisp subpixel text. Scrolling and zooming stay smooth no matter how long the document is.

Memory and caches are both bounded

Images, formulas and diagrams each have a clear cache limit; once it is exceeded, the least-recently-used content is dropped automatically, so editing a very large document for a long time never gets slower.

The direct result of these design choices: a light document sits at roughly 25 MB to 45 MB of memory, a hundred-thousand-line document holds steady between 60 MB and 110 MB, and neither grows the longer you keep editing.