Revalue the stock, three lookups at a time

FxDart wins async

Requirement

A warehouse holds stock items, each with a SKU, an on-hand quantity, and a book price. Refresh every unit price from a price service — at most three lookups in flight — falling back to the book price for SKUs the service doesn't know. Print the revalued stock total and how many items used the fallback. The service is simulated in the code below with a fixed delay; both versions must print the lines shown under Expected output.

Expected output

stock value: $4280.10
fallback prices used: 2
max lookups in flight: 3

Side by side

Native Dart

class Stock {
  final String sku;
  final int qty;
  final double bookPrice;
  const Stock(this.sku, this.qty, this.bookPrice);
}

const stock = [
  Stock('KB-01', 12, 49.00),
  Stock('MS-77', 30, 19.50),
  Stock('HD-15', 8, 74.25),
  Stock('CB-02', 55, 4.80),
  Stock('MN-24', 6, 189.00),
  Stock('DK-31', 3, 320.00),
  Stock('WC-09', 21, 12.40),
];

int inFlight = 0;
int maxInFlight = 0;

/// The price service knows most SKUs — not all.
Future<double?> livePrice(String sku) async {
  inFlight++;
  if (inFlight > maxInFlight) maxInFlight = inFlight;
  await Future.delayed(const Duration(milliseconds: 15));
  inFlight--;
  const prices = {
    'KB-01': 45.00, 'MS-77': 21.00, 'HD-15': 69.90,
    'CB-02': 5.10, 'MN-24': 175.00,
  };
  return prices[sku];
}

Future<void> main() async {
  // Worker pool: shared cursor, pre-sized slots so order survives.
  final repriced =
      List<({int qty, double price, bool fb})?>.filled(stock.length, null);
  var cursor = 0;
  Future<void> worker() async {
    while (cursor < stock.length) {
      final i = cursor++;
      final s = stock[i];
      final live = await livePrice(s.sku);
      repriced[i] = (qty: s.qty, price: live ?? s.bookPrice, fb: live == null);
    }
  }

await Future.wait([worker(), worker(), worker()]);

var total = 0.0;
  for (final r in repriced) {
    total += r!.qty * r.price;
  }
  final fallbacks = repriced.where((r) => r!.fb).length;

print('stock value: \$${total.toStringAsFixed(2)}');
  print('fallback prices used: $fallbacks');
  print('max lookups in flight: $maxInFlight');
}

FxDart

import 'package:fxdart/fxdart.dart';

class Stock {
  final String sku;
  final int qty;
  final double bookPrice;
  const Stock(this.sku, this.qty, this.bookPrice);
}

int inFlight = 0;
int maxInFlight = 0;

Future<void> main() async {
  final repriced = await fx(stock)
      .toAsync()
      .attach((s) => livePrice(s.sku))
      .concurrent(3)
      .map((r) => (qty: r.$1.qty, price: r.$2 ?? r.$1.bookPrice, fb: r.$2 == null))
      .toList();

final total = fx(repriced).sumBy((r) => r.qty * r.price);
  final fallbacks = fx(repriced).countWhere((r) => r.fb);

print('stock value: \$${total.toStringAsFixed(2)}');
  print('fallback prices used: $fallbacks');
  print('max lookups in flight: $maxInFlight');
}

Why they differ

Two hard parts stack here. The lookup must not lose its item — attach keeps each stock line beside the price the service returned (or null), which is what makes the fallback r.$2 ?? r.$1.bookPrice a one-liner. And the fan-out must be bounded — concurrent(3) is the limit as an operator, since attach rides the same parallel-safe machinery as map. The tallies fall out of the vocabulary: sumBy for the total, countWhere for the fallback count.

The native version has to build all of it: a shared-cursor worker pool for the limit, hand-made (item, price) records so the input survives the async hop, pre-sized result slots to keep order, and a where(…).length pass for the count. None of it is hard — all of it is ceremony that buries the four-step task.

Benchmark

Apple M1 Max, 32 GB RAM · Dart 3.12.2 (AOT-compiled) · 2026-08-24

Async case: the headline scale is N = 100,000, not 1,000,000. Every element costs an event-loop turn on both sides, so a million real awaits would measure Dart's event loop for minutes — not the pipeline. Delays are zero-length and the example's concurrency limit is kept; what the bars compare is the pipeline machinery.

N = 100

Time Tie

Native Dart 385 µs

FxDart 381 µs

Peak memory Tie

Native Dart 16.4 MB

FxDart 16.6 MB

N = 10,000

Time Native wins

Native Dart 30.5 ms

FxDart 34.1 ms

Peak memory FxDart wins

Native Dart 49.0 MB

FxDart 31.1 MB

N = 100,000

Time Native wins

Native Dart 310.9 ms

FxDart 352.9 ms

Peak memory Tie

Native Dart 80.8 MB

FxDart 80.5 MB

Bars are medians of repeated timed iterations in fresh processes per side (small N is batched for timer resolution). Sides within 5% of each other — or within 0.6 ms, a difference no person can perceive — count as a tie; close relative races are re-measured up to 5 runs. In an app, anything under a few milliseconds is invisible to the user regardless of which bar is shorter. Memory is peak process RSS. The Dart VM and the dataset are identical on both sides, so the difference between the two bars is what the pipeline itself holds onto.