Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling strings as numbers vs using regexp #136

Open
LeaVerou opened this issue Apr 4, 2021 · 1 comment
Open

Handling strings as numbers vs using regexp #136

LeaVerou opened this issue Apr 4, 2021 · 1 comment

Comments

@LeaVerou
Copy link
Collaborator

LeaVerou commented Apr 4, 2021

In jsep, I've seen this pattern a lot:

// `ch` is a character code in the next three functions
let isDecimalDigit = function(ch) {
	return (ch >= 48 && ch <= 57); // 0...9
};

let isIdentifierStart = function(ch) {
	return  (ch >= 65 && ch <= 90) || // A...Z
			(ch >= 97 && ch <= 122) || // a...z
			(ch >= 128 && !binary_ops[String.fromCharCode(ch)]) || // any non-ASCII that is not an operator
			(additional_identifier_chars.hasOwnProperty(String.fromCharCode(ch))); // additional characters
};

let isIdentifierPart = function(ch) {
	return 	(ch >= 65 && ch <= 90) || // A...Z
			(ch >= 97 && ch <= 122) || // a...z
			(ch >= 48 && ch <= 57) || // 0...9
			(ch >= 128 && !binary_ops[String.fromCharCode(ch)])|| // any non-ASCII that is not an operator
			(additional_identifier_chars.hasOwnProperty(String.fromCharCode(ch))); // additional characters
};

Is this done for performance?
If not, it would be far easier to just do e.g. /^[A-Z0-9]$/i.test(str) instead of (ch >= 65 && ch <= 90) || (ch >= 97 && ch <= 122) || (ch >= 48 && ch <= 57), but I imagine there is a reason it wasn't done this way?
We basically convert the string to a number before calling any of these functions, it's not like we even have the number in the first place.
Could these be optimizations the compiler can already do with a well anchored regexp?

@LeaVerou
Copy link
Collaborator Author

LeaVerou commented Apr 4, 2021

Indeed it must be performance: I just wrote a quick benchmark and the regex version seems to be about 70% slower in every browser. OTOH we are talking about a roughly 15ms total difference in 1,300,000 comparisons, so still not sure it's worth it, but I can see the point now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant