Benchmark: uint8array vs dataview extract

Script Preparation code:

// Creating an ArrayBuffer with the same data: [32-bit int, 16-bit int, 32-bit int]
// Using the same values for comparison: 1234567890, 12345, and 987654321
const buffer = new ArrayBuffer(10); // 4 bytes for int32, 2 bytes for int16, 4 bytes for another int32
const dataView = new DataView(buffer);

// Populating the buffer with our example data in little-endian format
dataView.setInt32(0, 1234567890, true); // 32-bit int at offset 0
dataView.setInt16(4, 12345, true);      // 16-bit int at offset 4
dataView.setInt32(6, 987654321, true);  // 32-bit int at offset 6
// Example buffer containing [32-bit int, 16-bit int, 32-bit int]
// For demonstration, let's create a buffer that represents the integers 1234567890 (0x499602D2), 12345 (0x3039), and 987654321 (0x3ADE68B1) in little-endian format
const bytes = new Uint8Array([
    0xD2, 0x02, 0x96, 0x49, // 1234567890 in little-endian
    0x39, 0x30,             // 12345 in little-endian
    0xB1, 0x68, 0xDE, 0x3A  // 987654321 in little-endian
]);

Tests:

dataview
// Reading the integers using DataView const int32_1 = dataView.getInt32(0, true); // First 32-bit integer, little-endian const int16 = dataView.getInt16(4, true); // 16-bit integer, little-endian const int32_2 = dataView.getInt32(6, true); // Second 32-bit integer, little-endian console.log(int32_1); // Outputs: 1234567890 console.log(int16); // Outputs: 12345 console.log(int32_2); // Outputs: 987654321
uint8array
// Function to read a 32-bit integer from a byte offset, assuming little-endian function readInt32LE(bytes, offset) { return (bytes[offset] | (bytes[offset + 1] << 8) | (bytes[offset + 2] << 16) | (bytes[offset + 3] << 24)) >>> 0; } // Function to read a 16-bit integer from a byte offset, assuming little-endian function readInt16LE(bytes, offset) { return bytes[offset] | (bytes[offset + 1] << 8); } // Extracting the integers const int32_1 = (bytes[0] | (bytes[0 + 1] << 8) | (bytes[0 + 2] << 16) | (bytes[0 + 3] << 24)) >>> 0; // First 32-bit integer const int16 = bytes[4] | (bytes[4 + 1] << 8); // 16-bit integer const int32_2 = (bytes[6] | (bytes[6 + 1] << 8) | (bytes[6 + 2] << 16) | (bytes[6 + 3] << 24)) >>> 0; // Second 32-bit integer console.log(int32_1); // Outputs: 1234567890 console.log(int16); // Outputs: 12345 console.log(int32_2); // Outputs: 987654321

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
dataview
uint8array

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Browser/OS: Chrome 131 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
dataview	149637.8 Ops/sec
uint8array	139167.2 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the benchmark and explain what's being tested.

**Overview**

The benchmark is testing two approaches for extracting integers from a buffer: `DataView` (specifically, `getInt32` and `getInt16`) and `uint8Array`. The goal is to measure which approach is faster.

**Options compared**

There are two options being compared:

1. **`DataView`**: This is a built-in JavaScript API that allows you to read and write binary data from an ArrayBuffer. It provides various methods for extracting integers, such as `getInt32` and `getInt16`.
2. **`uint8Array`**: This is a built-in JavaScript array type that can be used to store and manipulate binary data.

**Pros and Cons of each approach**

* **`DataView`**:
	+ Pros: Provides a convenient way to work with binary data, especially when dealing with fixed-size integers.
	+ Cons: May have performance overhead due to the need to interpret the data as a DataView object.
* **`uint8Array`**:
	+ Pros: Can be faster for small arrays or simple integer values, since it avoids the overhead of creating a DataView object.
	+ Cons: Requires manual manipulation of byte indices and may not provide as much convenience as `DataView`.

**Other considerations**

* The benchmark uses little-endian byte order to represent the integers. This means that the most significant byte comes first in memory.
* The `readInt32LE` and `readInt16LE` functions used in the `uint8Array` test case assume a specific byte order, which may not be portable across all platforms.

**Library usage**

There is no explicit library usage mentioned in this benchmark. However, `DataView` is a part of the JavaScript standard library, while `uint8Array` is also a built-in array type.

If you're new to JavaScript or haven't worked with binary data before, don't worry! This benchmark is meant to help you understand the differences between these two approaches and how they might impact your code.

As for alternatives, here are some options:

* **Native WebAssembly**: If you need high-performance integer operations, you might consider using Native WebAssembly (WASM) which provides direct access to hardware resources.
* **Native extensions**: Depending on the specific use case, native extensions like `uint8Array` or `DataView` might be replaced by custom, platform-specific code that can optimize performance.

If you're interested in exploring more alternatives or optimizing your own JavaScript code for better performance, I'd be happy to help!

Related benchmarks:

uint8array vs dataview extract (version: 2)

Comparing performance of: dataview vs uint8array

Created: 2 years ago by: Registered User

Jump to the latest result

dataview

uint8array

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):