~25% perf hit from version 2.0

[alexhuszagh]

~25% perf hit from version 2.0

[Alexhuszagh]

I've looked more at the differences between the two, and for a fairly rough, initial version of the float parser, I use subslices fairly extensively, which I am almost certain is incurring the performance hit. For more complex floats (those that are near halfway representations), which I was naively focusing on, the hit was fairly minimal. For simple data, it's 15-20%.

This should be trivial to fix with the same approach I used in the integer parser: simply tracking the current index.

[Alexhuszagh]

Let me profile with my sample data, I did notice some minor slowdowns with simple data, but I believe I might able to remediate this.

[Alexhuszagh]

Sorry, back from vacation, this should be fixed with the recent commit 26176a9. There's an undocumented feature unchecked_index (I will not document it, at least not until it has been thoroughly fuzzed), which will be present in version 2.1, that will disable bounds checking for some slice indexing, that should remove these performance hits.

I tried numerous things, and found ultimately I had to disable bounds checking in a few locations. However, doing so would be a nightmare if I ever refactored the code, since any analysis I had done to demonstrate that there could not be a memory error may no longer be valid after refactoring.

To mitigate this, I have two changes:

1. All the code is identical, with index and index_mut macros that use default Rust indexing by default, and with unchecked_index, disable bounds checks.
2. Every use of index or index_mut is elaborately explained, to help avoid refactoring from leading to memory errors.

For example, one of the comments is as follows:

// This is always safe, since the table is 2*radix^2, and the value
// must <= radix^2, so rem must be in the range [0, 2*radix^2-1).

[Alexhuszagh]

Added benchmarks in 0c45b01, this should be pushed to the latest release soon.

[Alexhuszagh]

Live as of lexical v2.1 and lexical-core v0.4.

You may use the feature unchecked_index to disable index checking in slices, which should restore this performance. This undocumented, but considered to be part of the public API, and therefore stable.