globby - chuhai

100%

globby - chuhai

✓ Published0🌍 Public

Last edited Jun 11, 2016

Created on Jun 11, 2016

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.

AI-generated description

Similar vizzes

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

64% match

Loading thumbnail…

chuhai async

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.

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

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…

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

55% 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…

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

54% match

Loading thumbnail…

run1:test (OK)

The example demonstrates how the Chomp build tool handles task targets containing wildcard `#` patterns, showing a working `run1:test` task alongside a truncated-path case for `run1:`. It compares command outputs where `./test.out` and `./st.out` are built, with the latter’s path shortened in the displayed terminal. The visualization uses plain terminal text from `chomp` runs, with validation set to `ok-only` and dependencies/targets defined in a TOML config. The data source is the tool’s own execution log, rendered as static shell snippets.

HHypercubed

53% match