isISIN optimization

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍

[bmacnaughton]

i was playing around and challenged myself to optimize isISIN. i'm not sure it's 100% there, but it's significantly more performant that it was.

$ node ./util.bench.js old-version
group times: [1390.93, 1344.84, 1396.37, 1426.44, 1408.29, 1373.00, 1517.00, 1381.53, 1372.97]
average per 100000: 1401.263
standard deviation of 9 intervals: 46.406
total: gc count: 1568, gc time: 137.500
done
$ node ./util.bench.js v3
group times: [211.69, 207.08, 213.71, 213.63, 214.08, 214.64, 213.91, 212.19, 213.39]
average per 100000: 212.703
standard deviation of 9 intervals: 2.168
total: gc count: 17, gc time: 3.633
done
## Checklist
- [x] PR contains only changes related; no stray files, etc.
- [x] README updated (where applicable) (NA)
- [x] Tests written (where applicable) (NA but one item added)

[codecov]

Codecov Report

Merging #1633 (c31da98) into master (deb1d1e) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1633 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 100 100 Lines 1807 1852 +45 =========================================
+ Hits 1807 1852 +45 

Impacted Files	Coverage Δ
src/lib/isISIN.js	100.00% <100.00%> (ø)
src/lib/isTaxID.js	100.00% <0.00%> (ø)
src/lib/isLicensePlate.js	100.00% <0.00%> (ø)
src/lib/isPassportNumber.js	100.00% <0.00%> (ø)
src/lib/isStrongPassword.js	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update deb1d1e...c31da98. Read the comment docs.

[tux-tn]

Thank you @bmacnaughton and sorry for the delay. A little question, isn't isISIN using the luhn algorithm?

[bmacnaughton]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

[tux-tn]

@tux-tn yes, it is. and it still is using the algorithm (it has to in order to work correctly). it's just executing it in one pass over the string now. but the performance benefits come mostly from not creating many substrings and running parseInt on each of them. it just makes one pass over the characters and converts them to the integer they represent directly.

i didn't really have any need for this, but whenever i see that kind of pattern in code i look at it as a puzzle to be solved. here's an example, completely unrelated to this, that shows another case where the performance of a slightly larger solution is dramatically better: https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript/55426656#55426656

Actually i was asking this to know if your optimization is related to luhn algorithm (other validators such as isCreditCard would profit from it) but after checking and running your code i understand that the optimization is related to string manipulation and type casting.
Thank you for taking the time to optimize the code and to do some benchmarking 👍