Benchmark: Benchmark for comparing common vs unique collator object on each sort iteration

HTML Preparation code:

<!--your preparation HTML code goes here-->

Script Preparation code:

var map = new Map([...Array(1000).keys()].map(a => ([a.toString(), 5])))

var options = {
  sensitivity: 'base'
};

var collator = new Intl.Collator(undefined, options);

Tests:

Using a common object
[...map.keys()].sort(collator.compare).map(k => ([k, map.get(k)]))
Using a separate object
[...map.keys()].sort((a, b) => {var collator = new Intl.Collator(undefined, options); return collator.compare(a, b)}).map(k => ([k, map.get(k)]))

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Using a common object
Using a separate object

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 22 days 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
Using a common object	8672.2 Ops/sec
Using a separate object	141.2 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 22 days ago):

LLMs can make mistakes. Check important info.

The benchmark conducted on MeasureThat.net evaluates the performance differences between using a single `Intl.Collator` object versus creating a new `Intl.Collator` object for each comparison during a sort operation. Let's break down the elements of the benchmark:

### Options Compared

1. **Using a Common Object**:
    - **Test Case**: 
      ```javascript
      [...map.keys()].sort(collator.compare).map(k => ([k, map.get(k)]))
      ```
    - **Description**: This test case utilizes a pre-created `collator` object for sorting the keys of the `map`. The `collator.compare` method is called repeatedly during the sort operation.

2. **Using a Separate Object**:
    - **Test Case**:
      ```javascript
      [...map.keys()].sort((a, b) => {var collator = new Intl.Collator(undefined, options); return collator.compare(a, b)}).map(k => ([k, map.get(k)]))
      ```
    - **Description**: In this case, a new `Intl.Collator` object is instantiated for each comparison being made during the sort.

### Pros and Cons of Each Approach

#### Using a Common Object:
- **Pros**:
  - **Performance**: More efficient because it avoids the repeated overhead of creating a new object for each comparison. 
  - **Memory Usage**: Uses less memory as only one instance is created and reused.
  
- **Cons**:
  - **Lack of Flexibility**: If there is a need to change the options dynamically during the sorting, it can be cumbersome.

#### Using a Separate Object:
- **Pros**:
  - **Flexibility**: If dynamic comparison criteria are needed, having a fresh `collator` allows for those adjustments with each call.
  
- **Cons**:
  - **Performance Overhead**: Significantly slower due to the overhead of creating an `Intl.Collator` instance repeatedly.
  - **Increased Memory Consumption**: Each instantiation requires additional memory, which can be impactful, especially with a high number of sort operations.

### Other Considerations
- **Performance Measurement**: The benchmark results indicate that using a common object (`collator`) resulted in approximately 9081.55 executions per second, while using a separate `collator` instance yielded only about 155.49 executions per second. This highlights the significant performance drop when repeatedly creating objects in performance-critical code.

### Library & Syntax
- **Intl.Collator**: 
  - This is a built-in JavaScript object that enables language-sensitive string comparison. It is part of the Internationalization API (Intl) and allows for sorting and comparing strings according to specific locale rules and options, such as case sensitivity. In this benchmark, the `sensitivity` option is set to `'base'`, which means that the comparison will ignore differences in accents or case (e.g., "A" and "a" would be considered equal).
  
### Alternatives
1. **Using Native Sort with Custom Comparison**: Similar to the separate object approach but without the `Intl.Collator`, simply use standard JavaScript string comparison (i.e., `a.localeCompare(b)`).
2. **Sorting Libraries**: Consider integrating libraries such as Lodash, which offer various utilities for sorting and might include options for locale-sensitive sorting.
3. **Memoizing Collator Objects**: To improve performance, one could create several collators beforehand based on expected sorting needs and use them as necessary, reducing instantiation time.
4. **Native JavaScript Comparison**: For cases where locale-specific sorting is not important, using the default `sort()` method with simple comparisons may suffice.

In summary, this benchmark is crucial for developers who need to understand the trade-offs between performance and flexibility when working with string comparisons in JavaScript, especially in context of internationalization. It gives clear insights on the cost of object instantiation in performance-critical sorting operations.

Related benchmarks:

Benchmark for comparing common vs unique collator object on each sort iteration (version: 1)

Comparing performance of: Using a common object vs Using a separate object

Created: 22 days ago by: Guest

Jump to the latest result

Using a common object

Using a separate object

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 22 days ago):