chuhai async

100%

✓ Published0🌍 Public

Last edited Jun 3, 2016

Created on Jun 2, 2016

This example demonstrates how asynchronous timing errors in benchmark code can skew results, contrasting a correct benchmark with a buggy variant. The visualization, generated by the `chuhai` and `blue-tape` libraries, compares operations per second for `nextTick`, `setTimeout`, and `setImmediate`, alongside a synchronous `max` baseline. In the buggy version, shared variable mutations inside asynchronous callbacks produce incorrect factorial calculations, as shown by failed assertions. The rendered bar chart highlights performance differences, with `nextTick` fastest when correct, while the buggy results falsely elevate `setImmediate` due to the timing mistakes.

AI-generated description

MIT Licensed

Similar vizzes

Loading thumbnail…

globby - chuhai

This example compares the performance of two glob-matching libraries—the local `globby` fork and the upstream `globby` master—against `glob-stream`, using the `chuhai` and `ava` benchmarking suites. It shows raw operations per second for three pattern scenarios (negative globs and multiple positive globs) across async and sync APIs, with results from 10 runs each. The code directly invokes `globby.sync()`, `globby()`, and `glob-stream`'s `create()` to measure throughput, while the markdown output lists the fastest implementation per test. Data is generated from a temporary directory containing 500 files per subfolder, and the rendering is plain text from benchmark results.

HHypercubed

62% match

Loading thumbnail…

Gist d6bacd4ce0d5835b801ba028f9b1c81b

This example benchmarks seven JavaScript object-cloning techniques using the `chuhai` benchmarking library, with `lodash`, `Object.assign`, and JSON methods. It compares operations per second for deep and shallow copies of 1,000 parsed CSV records fetched from a remote dataset. The visualization highlights relative performance differences through horizontal bar lengths, with the fastest method labeled explicitly. The code uses `babyparse` for CSV parsing and `platform` to report the runtime environment, while the benchmark logic is orchestrated via `suite.cb` and `s.bench` calls. Results are output as Markdown text, not rendered graphically.

HHypercubed

62% match

Loading thumbnail…

Gist e92adbf79e3256a0d3e222f140a0433b

This example visualizes the relative performance of 16 JavaScript event-emitter libraries across two benchmark scenarios, “emit objects” and “emit one parameter,” using the raw output of the benchmark runner. The data, drawn from a gist by Hypercubed, is rendered as a grouped horizontal bar chart where each bar’s length corresponds to operations per second (ops/sec), with libraries sorted by speed and the fastest highlighted. The chart uses a simple SVG-based custom layout (likely with d3-scale for axes and d3-array for sorting) rather than a high-level charting library, directly mapping the numeric values to pixel widths. The visualization does not show error margins or statistical significance, only the raw ops/sec values and the benchmark’s “Fastest is” annotation for each test.

HHypercubed

58% match

Loading thumbnail…

setTimeout/setInterval experiment involving slow-downs

This example demonstrates how `setTimeout` and `setInterval` differ in their behavior when a callback runs longer than the specified interval. It shows that `setInterval` can queue overlapping calls, while `setTimeout` waits for the previous execution to finish. The visualization uses a counter and a select menu to switch between the two methods, with a checkbox to artificially slow down the `tick` function via a blocking `while` loop. The code relies on D3.js v4 for DOM selection and event handling, and uses `window.setTimeout` and `window.setInterval` to schedule the counter updates. The counter increments by 0.5 every 500 milliseconds.

HHerst

57% match

Loading thumbnail…

Gist d51a566a307b428d98eaf3aa8d2a59a3

This example benchmarks JavaScript event emitter libraries across multiple test scenarios, including initialization, emitting with context, and emitting single or multiple values to one or more listeners. The code runs benchmark suites using `benchmark.js`, comparing libraries such as `EventEmitter3`, `MiniSignals`, `push-stream`, and `signal-lite`, and reports throughput in operations per second. It highlights the fastest performers per scenario, such as `push-stream` leading in the "emit with context" test. The visualization shows raw performance data from Node.js 6.2.1, rendered as plain-text tables with pass/fail assertions and timing summaries.

HHypercubed

57% match

Loading thumbnail…

PowerArray benchmarks

This visualization benchmarks the performance of different `forEach` implementations across arrays and typed arrays, showing that native methods on standard arrays are slower than optimized libraries like lodash, underscore, and fast.js, while PowerArray’s custom method rivals them. The bar chart compares operations per second (ops/sec) for each tested scenario, sourced from a benchmark suite generated by Node.js’s `Benchmark` module. The code uses `Benchmark.Suite` to run trials on plain arrays, `Uint16Array`, and PowerArray instances, with libraries like `fast.js`, `underscore`, `lodash`, and native `Array.prototype.forEach` called directly or via `.call`. Data comes from the gist’s `Results.txt` output, and the visualization likely plots these numeric results to highlight performance gaps.

HHypercubed

56% match

Loading thumbnail…

Gist 0e59d1c2d63aaea35573

This example demonstrates benchmark-driven optimization of recursion schemes in Haskell, using the Criterion library’s `defaultMain`, `bgroup`, and `bench` functions to measure performance. The code defines catamorphisms (`ffold`), anamorphisms (`funfold`), hylomorphisms, and build functions (`fbuild`, `funbuild`), then applies them to natural numbers, lists, and trees. It highlights how `INLINE` pragmas and `RULES` for fusion (e.g., `ffold/fbuild`) improve execution speed, as shown in benchmarks like `lengthL`, `mapL`, and `depthT` over sample data structures.

FFranklin Chen

54% match

Loading thumbnail…

Gist c0ec6bb768fd2672307b0807e4ee46fb

This example benchmarks four JavaScript loop styles—a standard `for` loop, a reversed `for` loop, a `for…of` loop, and `forEach`—on a fixed array of ten numbers. It measures execution time by repeating each loop a thousand times via `performance.now()` timestamps, accumulating the total milliseconds. The code defines each loop as a separate function and calls them through a `test` helper, logging the sum to the console. The comparison uses a simple in-memory data array, with no external libraries, focusing on raw loop performance in a JavaScript environment.

MMAKIO135

53% match