Why deno bench for benchmarking? - Purpose & Use Cases

The Big Idea

Discover how to stop guessing and start knowing which code runs faster in Deno!

The Scenario

Imagine you want to know which part of your Deno code runs faster, so you try timing it manually with Date.now() or console.time() scattered around your code.

The Problem

Manual timing is easy to mess up, inconsistent, and hard to compare across runs. You might forget to start or stop timers, or your measurements get noisy and unreliable.

The Solution

deno bench provides a built-in, reliable way to run benchmarks with precise timing and clear reports, so you can easily see which code is faster and by how much.

Before vs After

✗ Before

const start = Date.now();
// code to test
console.log('Time:', Date.now() - start, 'ms');

✓ After

import { bench } from "https://deno.land/std@0.203.0/testing/bench.ts";
bench(function myTest() {
  // code to test
});

What It Enables

You can confidently measure and compare performance of your Deno code with automated, repeatable benchmarks.

Real Life Example

When optimizing a sorting function, deno bench helps you see if your new approach is really faster before you ship it.

Key Takeaways

Manual timing is error-prone and inconsistent.

deno bench automates and standardizes benchmarking.

It helps you make better performance decisions confidently.

Practice

1. What is the main purpose of deno bench in Deno?

easy

A. To format code automatically

B. To check for syntax errors in code

C. To deploy Deno applications to the cloud

D. To measure how fast a piece of code runs

Solution

1. Step 1: Understand the role of benchmarking

   Benchmarking is used to measure the speed or performance of code.

2. Step 2: Identify what deno bench does

   deno bench runs benchmark tests to measure execution time of code snippets.

3. Final Answer:

   To measure how fast a piece of code runs -> Option D

4. Quick Check:

   Benchmarking = measuring speed [OK]

Hint: Benchmark means measuring speed or performance [OK]

Common Mistakes:

• Confusing benchmarking with syntax checking
• Thinking it deploys code
• Assuming it formats code automatically

2. Which of the following is the correct syntax to define a benchmark in Deno?

easy

A. bench({ name: "test", fn: () => { /* code */ } })

B. bench = function(name, fn) { /* code */ }

C. benchmark test() { /* code */ }

D. bench: { name = "test", fn() { /* code */ } }

Solution

1. Step 1: Recall the official benchmark syntax

   The correct way is to call bench with an object containing name and fn properties.

2. Step 2: Compare options to the correct pattern

   bench({ name: "test", fn: () => { /* code */ } }) matches the pattern bench({ name: "test", fn: () => { } }). Others are invalid syntax.

3. Final Answer:

   bench({ name: "test", fn: () => { /* code */ } }) -> Option A

4. Quick Check:

   Use object with name and fn keys [OK]

Hint: Use bench({ name, fn }) to define benchmarks [OK]

Common Mistakes:

• Using assignment instead of function call
• Incorrect object syntax
• Using invalid keywords like 'benchmark'

3. What will be the output behavior when running this benchmark code with deno bench?

bench({
  name: "sum test",
  fn() {
    let sum = 0;
    for (let i = 0; i < 1000; i++) {
      sum += i;
    }
  }
});

medium

A. It prints the time taken to run the loop 1000 times

B. It prints the sum value after the loop

C. It throws a syntax error because of missing return

D. It runs but does not show any output

Solution

1. Step 1: Understand what deno bench does

   It runs the benchmark function multiple times and reports the time taken.

2. Step 2: Analyze the code behavior

   The code sums numbers but does not return or print the sum. The benchmark tool measures execution time, not return values.

3. Final Answer:

   It prints the time taken to run the loop 1000 times -> Option A

4. Quick Check:

   Benchmarks show timing, not return values [OK]

Hint: Benchmarks report time, not return values [OK]

Common Mistakes:

• Expecting printed sum output
• Thinking a return is required
• Assuming no output is shown

4. Identify the error in this benchmark code:

bench({
  name: "test",
  fn: () => {
    let x = 0
    for (let i = 0; i < 10; i++) {
      x += i;
    }
  }
});

medium

A. Missing semicolon after let x = 0

B. Using arrow function instead of regular function

C. No error, code runs fine

D. Missing await keyword inside fn

Solution

1. Step 1: Check syntax carefully

   JavaScript allows optional semicolons. Automatic Semicolon Insertion (ASI) inserts a semicolon after let x = 0 before the for loop since for cannot continue the previous statement.

2. Step 2: Verify other potential issues

   Arrow functions are valid for fn. The code is synchronous, so no await is needed. The code is syntactically valid and runs fine.

3. Final Answer:

   No error, code runs fine -> Option C

4. Quick Check:

   ASI handles missing semicolon before for [OK]

Hint: Semicolons are optional in JS; ASI works before for loops [OK]

Common Mistakes:

• Thinking missing semicolon is a syntax error
• Believing arrow functions are invalid in benchmarks
• Assuming await is needed for synchronous loops

5. You want to benchmark two functions: one that sums numbers from 1 to 1000, and another that multiplies numbers from 1 to 1000. How should you write the benchmark code to compare their speeds correctly?

hard

A. Run one function inside bench and call the other outside

B. Define two separate bench calls each with a unique name and function

C. Put both functions inside one bench call and run them sequentially

D. Use bench only for the sum function and measure multiply manually

Solution

1. Step 1: Understand benchmarking multiple functions

   Each benchmark should be defined separately with a unique name to measure independently.

2. Step 2: Why separate bench calls are needed

   Running both in one bench mixes timings and does not isolate performance.

3. Final Answer:

   Define two separate bench calls each with a unique name and function -> Option B

4. Quick Check:

   Separate benchmarks for accurate comparison [OK]

Hint: Use separate bench calls with unique names [OK]

Common Mistakes:

• Combining multiple tests in one bench
• Measuring one function outside bench
• Skipping benchmark for one function