Think .dill. See Part 1.

It produces kernel (.dill) — parsed, type-checked, desugared intermediate code. It's shared so every backend (JIT VM, AOT, dart2js, Wasm) reuses one parser/type-checker instead of re-implementing it.

Development vs production.

JIT (development — dart run, flutter run, enables hot reload) and AOT (production — flutter build, dart compile exe).

A "save file" for program state.

A serialized image of program state (code and/or objects) written to a file so it can be loaded quickly later without redoing parse/compile work.

Machine code, plus a heap.

Native machine code plus a pre-initialized heap of already-built objects (including compile-time constants). A kernel snapshot only holds the kernel AST.

GC, scheduler, type checks...

The runtime provides garbage collection, the async event-loop scheduler, runtime type checks, isolate management, and core-library natives. AOT compiles your code but doesn't remove the need for these services; the runtime ships embedded.

dart compile ...

dart compile exe bin/main.dart -o app

Incremental + inject into running VM.

On reload, the CFE recompiles only changed libraries into a kernel delta and injects it into the running VM, which swaps code while keeping state. The compact, incrementally-producible kernel is what keeps the round trip sub-second.

Interpret → profile → optimize → maybe deopt.

It starts interpreted/baseline so it runs immediately, profiles call counts and types, and once "hot" the optimizing JIT compiles specialized machine code based on observed types — deoptimizing if an assumption is later violated.

Runtime knowledge AOT lacks.

The JIT observes real runtime types and frequencies and compiles speculatively specialized code (concrete types, inlining, devirtualization), deoptimizing if wrong. AOT compiles before any execution and must stay conservative. For long-lived hot paths, profile-guided specialization can win.

The one with hot reload.

Debug (flutter run). Profile and release are AOT.

Needs a runtime to load it.

An AOT machine-code snapshot (not a standalone exe). Run it with the AOT runtime:

dartaotruntime app.aot

Neither — different target.

Neither; for web Dart compiles to JavaScript (dart compile js) or WebAssembly (dart compile wasm), and the browser engine runs it. Same CFE front end, different backend.

What ships inside it?

It bundles the embedded Dart runtime (GC, scheduler, type system, core-library natives) alongside your compiled code. The runtime is the bulk of a tiny program's size.

State vs fresh main().

Hot reload injects new code and preserves app state (no main() re-run). Hot restart discards state and re-runs main() from scratch. Both require the JIT/debug build.

It's about timing.

JIT compiles while the program runs; AOT compiles before it runs. Every other trade-off follows from that.

Slow until hot paths optimize.

The early period where JIT code runs interpreted/baseline while being profiled before the optimizing compiler kicks in. AOT has no warm-up — it's pre-compiled.

Whole-program reachability.

Dead-code elimination — dropping anything unreachable from main(). AOT does it because it has the whole program statically before running, so it can prove what's unused. JIT can't (code can be added at runtime).

Is it reachable from main?

No — helperB is unreachable, so AOT tree-shakes it out. helperA stays.

Runtime code generation.

A JIT generates machine code at runtime (writable+executable memory), which iOS prohibits. AOT produces fixed native code ahead of time and complies.

debug / profile / release.

Debug = JIT (hot reload), Profile = AOT (+ DevTools hooks), Release = AOT (optimized, shipped).

Asserts on, optimizations off.

Debug is JIT with assertions on and optimizations effectively off (plus warm-up), so timings are unrepresentative and often many times slower than release. Profile in --profile/release.

A broken speculative assumption.

When optimized JIT code's speculative assumption (e.g. "always int") is violated at runtime, the VM deoptimizes — bails to the safe, general version — and may re-optimize later. It's how the JIT stays correct while being aggressive.

Wrong build mode.

Re-measure in profile or release (AOT) mode. Debug timings (JIT, asserts on) are not representative.

Polymorphic → direct call.

Turning a polymorphic (virtual) call into a direct one when analysis proves a single possible target. AOT's whole-program analysis lets it find such cases (e.g. a class with one implementation), removing dispatch overhead.

Inject code into a running program.

JIT — only it can inject new code into an already-running program. AOT code is frozen and has no compiler present.

Every reachable function's machine code.

AOT ships native machine code for all reachable functions up front (plus the runtime), whereas JIT ships compact kernel and compiles lazily. (AOT offsets this with tree shaking.)

Frame times.

Real-time UI rendering: AOT has no mid-run deopt/recompile pauses, giving consistent frame times — preferable to a JIT that might pause to recompile during an animation, even if its peak throughput is similar.

AOT + tooling hooks.

Profile mode: flutter run --profile. AOT timings with enough hooks for the timeline/CPU profiler.

Different priorities at dev vs ship time.

Development prizes iteration speed (hot reload → JIT); shipping prizes startup, predictability, and platform compliance (→ AOT). Using each where it wins gives sub-second reload and fast, jank-free release apps.

Can the roots reach it?

Reachability from the roots (stack locals, statics, globals). Unreachable objects are garbage. There's no manual free.

Most objects...

Most objects die young — created, used briefly, discarded — while a few live long. Dart's GC is built around this.

Copy survivors only.

New space has two halves; when one fills, the scavenger copies live objects to the other half and frees the old half wholesale. Cost is proportional to survivors, not garbage, so high churn with few survivors is cheap.

Pointer bump.

Allocation is a bump-pointer in a contiguous region — advance the "next free" pointer. That's why making lots of short-lived widgets is cheap.

Mark, sweep, and...

A mark-sweep collector, with compaction (sliding live objects together) to keep free memory contiguous.

Concurrent + idle.

Concurrent marking (and parallel phases) keeps stop-the-world pauses short, and Flutter signals idle periods so GC runs between frames rather than mid-animation.

What does nothing point to?

User('1') — nothing references it after a = b. User('2') is alive (both a and b point to it).

Reachable ≠ needed.

GC only reclaims unreachable objects. Keeping something reachable you no longer need — undisposed subscriptions/controllers, closures capturing this, unbounded caches — leaks it. The GC works; the references are the bug.

What's missing?

No dispose cancels _sub, so the subscription keeps the State alive. Fix:

@override
void dispose() {
  _sub.cancel();
  super.dispose();
}

Promotion.

It's promoted to old space. Surviving repeated scavenges marks it as long-lived (generational hypothesis), so it stops being repeatedly copied and is handled by the old-space collector.

Separate heaps.

Each isolate has its own heap and GC (no shared mutable memory; messages are copied/transferred), so GC in one never pauses another. Offloading work to a background isolate keeps its allocation churn off the UI isolate.

Weak.

Use WeakReference<Image> (or a bounded/LRU cache). A plain Map<String, Image> keeps every value strongly reachable, so the GC can never reclaim them — an unbounded cache becomes a leak.

Cleanup after collection, non-deterministic.

It runs a cleanup callback after an object is collected (e.g. releasing a native resource). The catch: timing is non-deterministic and best-effort, so prefer explicit dispose() and use it only as a safety net.

Never evicts.

_m only grows and is static (always reachable), so all values stay alive forever. Bound it with an LRU/size cap (evict oldest on insert) or use WeakReference values.

Snapshots + retaining path.

Repeat push/pop several times, take a heap snapshot (or diff two), check whether instances of that screen's State accumulate, and follow the retaining path to the reference you failed to release in dispose().

When is the value known?

final is assigned once at runtime; const is a compile-time constant, known before the program runs and deeply immutable.

Is DateTime.now() known at compile time?

Only b fails — DateTime.now() isn't a constant expression. a and c are fine.

Immutability.

All instance fields final, empty constructor body (init via initializer list/field initializers), and no non-const superclass generative constructor. To invoke as const, all arguments must be constant.

Canonicalization.

true — identical const values are canonicalized to one shared instance.

One instance program-wide.

For a given const expression, Dart creates exactly one shared instance and reuses it everywhere, so equal constants are identical().

Allocation + rebuilds.

(1) No allocation — a const widget is a canonical instance built once (into the snapshot heap), never re-allocated. (2) Skipped rebuilds — its identity stays the same, so Flutter can prune that subtree from the rebuild/diff walk.

Fields + constructor.

class Vector {
  final double x, y;
  const Vector(this.x, this.y);
}

Call-site const.

No. It enables it. Foo(runtimeValue) builds at runtime because the argument isn't constant. You need const at the call site (or an enclosing const context) and constant arguments.

Snapshot heap.

In the AOT snapshot's pre-initialized heap (Part 1) — built at compile time. Saves runtime allocation and any GC work for it.

It never changes.

It's fully constant, so const Icon(...) is one canonical instance reused every rebuild (no re-allocation, prunable on rebuild). Hence the prefer_const_constructors lint.

Compiler evaluates them.

Case labels are resolved by the compiler into constant dispatch and must be known/comparable at compile time, so non-constant expressions aren't allowed.

Propagation.

No — inside an already-const context, const propagates downward, so EdgeInsets.all(8) and Text('Hi') are implicitly const.

Same instance.

Identical constants are the same object, so identical() (and == short-circuiting on identity) returns instantly without field comparison — which Flutter leverages to detect unchanged widgets.

Is const present?

No. Without const at the call site it's a runtime allocation, not the canonicalized compile-time object. You must write const Icon(Icons.star) to get the shared instance.

Foreign functions.

Foreign Function Interface — calling native (C) code directly. dart:ffi loads native libraries, describes signatures, marshals arguments, and works with native pointers/structs.

Sync call vs async message.

FFI is a direct synchronous native call in the same process (low overhead, C-level responsibility). Platform channels are asynchronous message passing to Kotlin/Swift (serialized, thread-hopping).

Native types vs Dart types.

typedef NativeScale = Double Function(Double, Int32);
typedef DartScale = double Function(double, int);
final scale = lib.lookupFunction<NativeScale, DartScale>('scale');

ABI vs friendly API.

The native signature (Int32, Double, Pointer<T>) describes the exact C ABI/bit layout; the Dart signature (int, double) is the friendly API. lookupFunction marshals between them.

Not the GC.

You do. Native allocations live outside the Dart heap, so the GC doesn't track them. Every malloc/calloc needs a matching free, or you leak.

toNativeUtf8 allocates native memory.

void greet(String name) {
  final c = name.toNativeUtf8();
  try {
    nativeGreet(c);
  } finally {
    calloc.free(c);
  }
}

Dereference.

It dereferences the pointer to the struct instance backed by that native memory, so p.ref.field = x writes directly into the C layout.

extends Struct, @Double().

final class Coord extends Struct {
  @Double()
  external double x;
  @Double()
  external double y;
}

Synchronous on the thread.

FFI calls run synchronously on the calling isolate's thread; a long native call blocks the UI isolate's event loop so frames can't paint. Fix: run it on a background isolate (e.g. Isolate.run).

Same thread vs other thread.

isolateLocal is synchronous and must be invoked on the owning isolate's thread (use for same-thread callbacks needing a return). listener posts asynchronously to the isolate's event queue — required for callbacks fired from another thread.

Both Dart double.

C double → ffi Double, C float → ffi Float; both surface as Dart double. The native type controls bit width.

Parse headers.

It parses C headers and generates type-safe Dart bindings, so you don't hand-write the two-signature dance for large libraries. (It's build-time codegen — Part 7.)

Separate heaps; raw addresses.

Isolates have separate heaps and messages are copied; a Pointer is a raw native address with no managed wrapper to copy safely, and ownership/lifetime get murky. Typically you perform the whole native interaction inside one isolate (passing the address as an int only when you really know what you're doing).

Free native memory when the Dart wrapper dies.

It ties a native resource's cleanup (e.g. free) to a Dart object's lifecycle: when the wrapper is collected, the finalizer runs. It's a safety net for native memory the GC can't manage — but explicit dispose() is preferred since finalizer timing is non-deterministic.

JIT + asserts.

Debug is JIT with asserts on and optimizations off — unrepresentative. Profile mode is AOT (real timings) with DevTools hooks.

Width = time.

Width = time spent in that function (+ callees). Optimize the widest boxes; ignore the thin ones.

Runs every frame.

build() can run every frame, so sorting/parsing/formatting there repeats per rebuild. Compute once when data changes and cache; build() should only describe UI.

StringBuffer.

final b = StringBuffer();
for (final n in nums) b.write('$n,');
final s = b.toString();

+= is ~O(n²) copying; StringBuffer is O(n).

Lazy re-iteration.

p is a lazy iterable; heavy re-runs on each iteration (here twice). Materialize once: final p = items.map(heavy).toList();.

Set.

final u = input.toSet().toList();

List.contains is O(n) → O(n²) loop; Set membership is O(1) average → O(n).

CPU vs I/O.

Helps for CPU-bound work that blocks the UI isolate (parsing, image processing). Does nothing extra for pure I/O waiting, which async/await already handles without blocking the thread.

Boxing + locality.

Uint8List is contiguous and unboxed — compact, cache-friendly, little GC churn. List<int> may box elements and is larger, hurting large numeric/byte workloads.

Warms up and averages.

package:benchmark_harness (compiled AOT), not a single Stopwatch read — it warms up and averages many runs.

Smallest subtree.

Rebuild the smallest subtree depending on the changed state: push setState down, use const to fence static subtrees, and watch the narrowest state slice with a state manager. DevTools' rebuild stats highlight offenders.

Chain lazily, materialize once.

final b = nums.where((n) => n.isEven).map((n) => n * n).toList();

One pass, no throwaway intermediate list — less allocation/GC pressure.

Premature vs none.

Premature optimization (complicating cold paths the profiler shows are irrelevant) and no optimization (shipping obvious O(n²)/per-frame parsing). The cure for both is profile-driven, targeted fixes.

Allocation pressure.

Excess short-lived allocation per frame (Part 3) — e.g. non-const widgets, per-frame object/closure creation. Add const (Part 4), hoist invariants out of build(), and reuse buffers to cut churn.

Measure, fix widest, repeat.

Profile (in profile/release) → find the widest box → understand why (allocation, complexity, blocking, or rebuilds) → fix that one thing → profile again — and stop when under budget.

Code about code.

Code that inspects or generates code — in Dart, mainly to eliminate boilerplate (serialization, data-class members, DI/routing, bindings) via build-time generation.

Tree shaking.

Runtime reflection defeats AOT tree-shaking (Part 2) — nothing can be proven unused — so it's unsupported in Flutter/AOT. Static codegen keeps the program tree-shakeable.

Orchestrator + helper layer.

build_runner orchestrates builders that read source and write generated files (cached, incremental). source_gen is a layer on top simplifying annotation-driven generators.

Annotation, part, command.

@JsonSerializable() annotation, part 'x.g.dart'; directive, and dart run build_runner build.

Private access.

It makes the generated file a part of your library, so generated members can access the library's private members (_$FooFromJson). You wire generated code in via part, never by editing it.

A --delete-... flag.

dart run build_runner build --delete-conflicting-outputs

Build-time only.

No. Generation runs at build time and emits ordinary .dart that's then compiled normally. At runtime there's no reflection or generation — just compiled code.

Elements in, String out.

It extends GeneratorForAnnotation<T>, receives the analyzed program as Elements (analyzer package), inspects them, and returns Dart source as a String that build_runner writes out. It's "templating with type info."

Hot reload performance.

January 2025. Macros had to re-run during incremental compilation, slowing hot reload below Flutter's bar. The team couldn't get acceptable performance and shelved them indefinitely.

augment + better build_runner.

Augmentations (the augment keyword to split declarations across files) and a commitment to improving build_runner. build_runner remains the standard.

Add to the same class.

augment class User { ... } lets generated code add members to the existing class (and fill in bodies) from another file, instead of only adding top-level _$... helpers glued via part. Cleaner generated APIs.

freezed, riverpod_generator, drift...

E.g. freezed (immutable data classes/unions/copyWith), riverpod_generator (providers from @riverpod), drift (SQL access), retrofit (HTTP clients), json_serializable (serialization).

Performance shapes features.

Macros conflicted with hot reload — the JIT-powered (Part 2) fast iteration that defines Flutter. Dart chose that performance over the feature. Performance constraints shape what Dart can even be — the through-line of the whole series.

Macros aren't coming.

Macros were cancelled (Jan 2025) and aren't coming — there's no in-language no-build-step option. Use build_runner + json_serializable/freezed; it's the stable, blessed path, and augmentations are quietly improving the experience.

main, a, and b survive. main calls a, which calls b — all reachable. c is never reached from main, so tree shaking (Part 2) removes it.

Widget build(BuildContext context) {
  return const Padding(
    padding: EdgeInsets.all(8),
    child: Column(children: [
      Text('Title', style: TextStyle(fontSize: 20)),
      SizedBox(height: 8),
      Text('Subtitle'),
    ]),
  );
}

The whole subtree is static, so one outer const makes the entire tree a canonicalized compile-time object: zero per-frame allocation and Flutter can skip rebuilding it (identity unchanged). const propagates to the inner EdgeInsets, TextStyle, SizedBox, and Text (Part 4).

Add a dispose that tears down everything with a lifecycle:

@override
void dispose() {
  _sub.cancel();
  _anim.dispose();
  _controller.dispose();
  super.dispose();
}

Each held StreamSubscription/AnimationController/ScrollController keeps the State (and its subtree) reachable until released (Part 3). Confirm with a DevTools heap snapshot that _FeedState instances no longer accumulate.

reports() returns a lazy iterable, so parseReport re-runs on every traversal — here three times. Materialize once:

void summarize() {
  final r = raw.map(parseReport).toList();
  print('count: ${r.length}');
  print('failed: ${r.where((x) => x.failed).length}');
  print('first: ${r.first.id}');
}

Now parseReport runs exactly once per item (Part 6).

onPressed: () async {
  final data = await Isolate.run(() => jsonDecode(hugeString));
  setState(() => _data = data);
}

jsonDecode is CPU-bound; on the UI isolate it blocks the event loop for ~1.5 s, so frames can't paint (Part 2). Running it on a background isolate (or compute) keeps the UI thread free. async/await alone wouldn't help — there's nothing to wait on (Part 6).

import 'dart:ffi';
import 'package:ffi/ffi.dart';

typedef NativeSum = Int32 Function(Pointer<Int32>, Int32);
typedef DartSum = int Function(Pointer<Int32>, int);

int sumOf(DynamicLibrary lib, List<int> values) {
  final sumArray = lib.lookupFunction<NativeSum, DartSum>('sum_array');
  final buf = calloc<Int32>(values.length);
  try {
    for (var i = 0; i < values.length; i++) {
      buf[i] = values[i];
    }
    return sumArray(buf, values.length);
  } finally {
    calloc.free(buf); // native memory the GC won't reclaim ([Part 5])
  }
}

The try/finally guarantees the native buffer is freed even if the call throws (Part 5).

List<Order> withCustomer(List<Order> orders, List<Customer> customers) {
  final ids = {for (final c in customers) c.id}; // Set, O(1) lookup
  return orders.where((o) => ids.contains(o.customerId)).toList();
}

The original is O(orders × customers) (a linear any scan per order). Building a Set of customer ids once makes membership O(1), giving O(orders + customers) (Part 6).

import 'package:json_annotation/json_annotation.dart';

part 'user.g.dart';

@JsonSerializable()
class User {
  final String name;
  final int age;
  User(this.name, this.age);

  factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
  Map<String, dynamic> toJson() => _$UserToJson(this);
}

dart run build_runner build --delete-conflicting-outputs

Annotation + part + command — the universal codegen pattern (Part 7).

decodeAndResize() is synchronous CPU work on the UI isolate's single thread. While it runs, the event loop can't process the "paint frame" event, so ~36 frames are missed (600 ms ÷ ~16 ms) — visible jank (Part 2, Part 3). The flame chart's wide box pinpoints it (Part 6). Fix: move it to a background isolate (Isolate.run/compute), or, if it wraps a native codec, call that via FFI inside a worker isolate (Part 5). Re-profile to confirm the UI thread is clear.

// 1. Immutable model with a const constructor (Part 4): zero-alloc reuse,
//    cheap equality, safe to share across isolates.
class Row {
  final String id;
  final int amount;
  const Row(this.id, this.amount);
}

// 2. Generated persistence layer (Part 7): build_runner + a package like
//    drift generates the type-safe DB code — no runtime reflection (Part 2),
//    so AOT tree-shaking stays intact.
//    @DriftDatabase(...) class AppDb ... → app_db.g.dart

Future<void> importCsv(String path, AppDb db) async {
  // 3. Read + parse on a BACKGROUND ISOLATE (Parts 2,3,6): CPU-bound parsing
  //    must not block the UI isolate, or frames stop painting.
  final rows = await Isolate.run(() {
    final text = File(path).readAsStringSync();      // I/O off the UI isolate too
    final buffer = <Row>[];                           // grows once
    for (final line in const LineSplitter().convert(text)) {
      final parts = line.split(',');
      buffer.add(Row(parts[0], int.parse(parts[1]))); // build models
    }
    // 4. Dedupe with a Set, O(n) not O(n²) (Part 6):
    final seen = <String>{};
    return [for (final r in buffer) if (seen.add(r.id)) r];
  });

  // 5. Persist via the generated layer. Batched insert keeps it efficient.
  await db.batchInsert(rows);
  // The worker's heap (with all the parse garbage) is GC'd independently of
  // the UI isolate (Part 3) — its allocation churn never touched our frames.
}

// 6. The UI just awaits and rebuilds the SMALLEST subtree (Part 6),
//    with const widgets fencing the static parts (Part 4).

Concept map:

• Const models — Part 4: immutable, canonicalizable, cheap equality, safe to pass between isolates.
• Background isolate for parsing + I/O — Part 2/Part 3/Part 6: CPU work off the UI thread so the event loop keeps painting; the worker's GC is independent.
• Set-based dedupe — Part 6: O(n) membership instead of O(n²).
• Generated DB layer — Part 7: build_runner codegen, which exists because runtime reflection would break AOT tree-shaking (Part 2).
• GC awareness — Part 3: the parse garbage lives and dies in the worker's heap.
• Profile to verify — Part 6: confirm in profile mode that the UI thread stays under frame budget throughout the import.

If you can explain why each choice is the performant one, you've internalized the whole series.