|The stupid question is the question not asked|
Re^10: Faster Luhn Check Digit Calculation?by BrowserUk (Patriarch)
|on Dec 02, 2018 at 09:08 UTC||Need Help??|
At least according to godbolt.org, the three routines don't get folded into the same assembly code.
I didn't really expect that they would be; but the empirical evidence is that they take the same amount of time. The routine is now so stripped down to the essentials that the calling overheads are beginning to dominate.
For example, the OPs original test code used a numeric range for testing:401135000000000..401135000999999 which I just copy&pasted. That means that every call to the function carries the overhead of converting those integers to strings. Switching the range to strings: '401135000000000' .. '401135000999999' avoids that conversion and saves more time than tybalt's optimisations.
Other changes that would require knowledge of how that code is used are also more likely to affect the performance. Eg. If the code's purpose is to verify existing CC numbers (rather than constructing new ones) then is is likely that the 16-digits strings are being read from a file or DB. Then the 16-digits are truncated to 15, passed into the routine, the checkdigit is calculated and returned and that is then compared against the 16th digit of the input.
If the routine was rewritten to accept the 16 digits and return a boolean indicating T/F then several operations external to the routine could be eliminated and overall throughput improved even though the function itself might be a little slower.
Only the OP can decide what comes next.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit