Skip to main content
100%

Gist 3852c326558525b3b1489f2be531f4b5

✓ Published0🌍 Public
Aabernier
Last edited Aug 26, 2020
Created on Aug 25, 2020

This visualization compares the performance of two JavaScript implementations of a "persistent bugger" algorithm, which calculates the persistence of a number by repeatedly multiplying its digits until a single digit remains. The benchmark, generated via perf.link, plots execution times (in operations per second) for the recursive `persistenceA` versus the iterative `persistenceB` approach across repeated test runs on the input 99999. A linked bar chart visualizes the runtime distributions, making it easy to compare the relative efficiency of the two code variants.

AI-generated description

Persistent bugger: https://www.codewars.com/kata/55bf01e5a717a0d57e0000ec

📊 Compare perfs of different versions.

Similar vizzes

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
66% match
Loading thumbnail…

Gist 9ef6442a63b8d2372fbf0c08916bdb88

This visualization compares four JavaScript implementations of the maximum subarray problem in a single file, using plain arrays and arithmetic operations. The code defines `maxSubArray01` through `maxSubArray04`, each with distinct algorithmic strategies: brute-force nested loops, greedy accumulation with `Math.max`, dynamic programming with an auxiliary array, and an in-place DP variant that mutates the input. No external visualization libraries are used; the example relies solely on standard JavaScript array methods and `Math.max` to illustrate trade-offs between time and space complexity. The gist serves as a code-level comparison rather than a graphical chart.

Aamazingandyyy
62% match
Loading thumbnail…

Turbo.js Speed Test

Two animated bars compare the average execution duration of identical array multiplication tasks in vanilla JavaScript and turbo.js, with a slider controlling the test array length from 1e1 to 1e7 and buttons to start, stop, or reset the benchmark. The SVG chart, built with d3.v4, updates each animation frame as the tests run, displaying the cumulative mean duration per iteration and the iteration count. The vanilla test uses a standard `for...in` loop over a plain array, while the turbo.js test processes its allocated data buffer through a GPU kernel via `turbojs.run`, with results rendered as horizontal rectangles whose widths scale to the measured milliseconds.

Aalexmacy
61% match
Loading thumbnail…

Gist 9442b080af40909ec71d

This animation visualizes performance data collected from a development tools session. The code periodically dumps accumulated performance metrics to a file, writing each batch of records as comma-separated JSON objects appended to `devtools.json`. It uses `fs.appendFile` to write data every 3 seconds, managing the first-write flag to properly format the array. The visualization relies on a global `perfs` array that stores performance entries, which are serialized and output without any charting or rendering library.

Aali-bugdayci
61% 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
60% 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
60% 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
59% 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
58% match