Node's zlib, on the calling thread. Deliberately not zlib's async API:
measured on a worldwide file, handing blocks to libuv's thread pool made
a burst of zoomed-out map tiles 15-40% slower and cold lookups ~30%
slower, while barely shortening the longest event-loop stall -- parsing
a decoded chunk costs more than inflating it, and that stays on this
thread either way. What keeps the event loop responsive is that every
chunk read (FileSource.read) is asynchronous, so the loop gets a turn
between chunks: a stall is one chunk's decode (~25 ms for the largest
chunk of a worldwide file, most far less), not a whole tile's or batch's.
Node's zlib, on the calling thread. Deliberately not zlib's async API: measured on a worldwide file, handing blocks to libuv's thread pool made a burst of zoomed-out map tiles 15-40% slower and cold lookups ~30% slower, while barely shortening the longest event-loop stall -- parsing a decoded chunk costs more than inflating it, and that stays on this thread either way. What keeps the event loop responsive is that every chunk read (
FileSource.read) is asynchronous, so the loop gets a turn between chunks: a stall is one chunk's decode (~25 ms for the largest chunk of a worldwide file, most far less), not a whole tile's or batch's.