Timeline for Custom double parser optimized for performance
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2020 at 13:24 | history | edited | Community Bot |
Commonmark migration
|
|
| Aug 3, 2018 at 15:23 | comment | added | Alain | Let us continue this discussion in chat. | |
| Aug 3, 2018 at 15:18 | comment | added | Alain |
Alright, I tried a new version where all I changed was to transfer the characters of input to a new array input.Length + 1. I guess all that memory allocation is super expensive. It took performance down from +300% to +90%. Code was: char[] characters = new char[length + 1]; input.CopyTo(0, characters, 0, length); characters[length] = '0円'; I can try simplifying all the while loop conditions to no longer check for the length, but I don't think it can recover the time taken to allocate the new character array.
|
|
| Aug 3, 2018 at 14:40 | comment | added | chux |
Other idea: consider profiling a table lookup isdigit[nextChar] instead of if (nextChar > '9' || nextChar < '0').
|
|
| Aug 3, 2018 at 14:39 | comment | added | chux | "think of any way without building a new array?" --> No, yet appending to the existing array may not cost much. | |
| Aug 3, 2018 at 14:30 | comment | added | Alain | That's a good idea. If only strings in c# returned the null character as the last element in their character array like c++. Can you think of any way without building a new array? | |
| Aug 3, 2018 at 14:20 | comment | added | chux |
Code like do { nextChar = input[currentIndex]; if (nextChar > '9' || nextChar < '0') break; result = result * 10d + (nextChar - '0'); } while (++currentIndex < length); is doing 2 checks (is digit, is at end) per loop to see if it should stop. If able, append a non-digit to index[] and then code only need to to check for digit. After to loop code can test if loop quit due to end of string or not. `
|
|
| Aug 3, 2018 at 12:36 | comment | added | Alain | @chux I applied your suggestion in this updated version and it took the performance up another ~15% - while still supporting all valid double cases. The results still differ from Native Double.Parse by 1 or 2 ULPs for certain very large or very small numbers, but I don't consider that a meaningful drawback. It just means results aren't always being parsed to precisely the closest possible double representation of the string processed. | |
| Aug 3, 2018 at 12:33 | history | edited | Alain | CC BY-SA 4.0 |
Made changes to remove the need for a separate 'fraction' part as suggested.
|
| Aug 2, 2018 at 16:15 | history | edited | Alain | CC BY-SA 4.0 |
Indentation got messed up
|
| Aug 2, 2018 at 16:08 | history | answered | Alain | CC BY-SA 4.0 |