Toggle navigation
MeasureThat.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
Compare strings, localeCompare vs Intl.Collator API vs strict equality
(version: 0)
This test measures which is faster, compare a string using localeCompare method, the Intl.Collator API or a strict equality
Comparing performance of:
localeCompare vs Intl.Collator API vs strict equality
Created:
2 years ago
by:
Registered User
Jump to the latest result
Script Preparation code:
var nodeName = 'HA-CARD'; var collator = new Intl.Collator('en', { sensitivity: 'base' });
Tests:
localeCompare
var equal = false; if (nodeName.localeCompare('ha-card', 'en', { sensitivity: 'base' }) === 0) { equal = true; }
Intl.Collator API
var equal = false; if (collator.compare(nodeName, 'ha-card') === 0) { equal = true; }
strict equality
var equal = false; if (nodeName === 'HA-CARD') { equal = true; }
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (3)
Previous results
Fork
Test case name
Result
localeCompare
Intl.Collator API
strict equality
Fastest:
N/A
Slowest:
N/A
Latest run results:
Run details:
(Test run date:
2 years ago
)
User agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Browser/OS:
Chrome 124 on Mac OS X 10.15.7
View result in a separate tab
Embed
Embed Benchmark Result
Test name
Executions per second
localeCompare
313120.5 Ops/sec
Intl.Collator API
8537777.0 Ops/sec
strict equality
28131958.0 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
Let's break down the provided JSON and explain what is tested on the website. **What is tested?** The test measures the performance of three different approaches to compare strings: 1. `localeCompare` method (using the built-in string comparison function) 2. The Intl.Collator API (a new standard for comparing strings in JavaScript, introduced in ECMAScript 2019) 3. Strict equality (`===`) **Options compared** The test compares the execution time of each approach: * `localeCompare` with options: + Case sensitivity: `sensitivity` option set to `'base'` + Locale: English locale (`'en'`) * Intl.Collator API with options: + Locale: English locale (`'en'`) + Sensitivity: `sensitivity` option set to `'base'` * Strict equality (no options) **Pros and cons of each approach** 1. **localeCompare**: This is the built-in string comparison function in JavaScript, which is widely supported by most browsers. It's a simple and efficient way to compare strings. However, it may not handle all edge cases, such as non-ASCII characters or locale-specific comparisons. 2. **Intl.Collator API**: This is a new standard for comparing strings, introduced in ECMAScript 2019. It provides more features than the built-in `localeCompare` method, such as handling non-ASCII characters and locale-specific comparisons. However, it may not be supported by all browsers or versions. 3. **Strict equality (`===`)**: This approach is simple and efficient but may not handle edge cases, such as non-ASCII characters. **Other considerations** When choosing a string comparison method, consider the following factors: * **Locale**: If you need to compare strings in different locales, use the Intl.Collator API or localeCompare with options. * **Non-ASCII characters**: Use the Intl.Collator API if you need to handle non-ASCII characters. * **Browser support**: Make sure the chosen approach is supported by your target browsers. **Library** The Intl.Collator API uses a library that provides the necessary functionality for comparing strings. The exact implementation may vary depending on the browser and version. **Special JS feature or syntax** This test does not use any special JavaScript features or syntax, such as async/await, promises, or modern language features like let or const declarations. **Alternatives** If you need to compare strings in JavaScript, consider using the following alternatives: * Other string comparison functions: `String.prototype.localeCompare` (not supported in all browsers), `String.prototype.normalize` followed by a case-insensitive comparison * Third-party libraries: `string-locale`, `localejs` * Custom implementation using regular expressions or other techniques
Related benchmarks:
another test 2
toFixed vs toPrecision vs Math.round() fast vs Math.floorfast vs new Math.trunc
toFixed vs toPrecision vs Math.round() vs Math.floorfast vs new Math.trunc str dynamic
floor vs trunc vs bit shift
What's faster? cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString currency
Comments
Confirm delete:
Do you really want to delete benchmark?