| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
It's quite a bit faster, and easier to understand.
|
|
|
|
|
| |
This version gives more attention to the relevant details, namely how
HMAC performs under different key lengths.
|
|
|
|
|
| |
Also, simplify the function a bit. It's faster this way, even though
there's an additional unconditional collect() call now.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
soulsource/feature/heap-allocation-free-base-conversion
Feature/heap allocation free base conversion
While skipping the heap allocation is nice, the real gain is the option to early-out of password generation once the desired length has been reached.
|
| |
| |
| |
| | |
It's done, so no point in keeping the TODO around :D
|
| |
| |
| |
| | |
Now Clippy is happy.
|
| |
| |
| |
| |
| | |
Some were fixed, some were ignored because they seem to make a
(negative) performance impact.
|
| |
| |
| |
| |
| | |
These tests compare the code for iterative base conversion with the
alternative formula that spits out digits in reverse order.
|
| |
| |
| |
| |
| |
| | |
Having one function that does both seems to be measurably faster, though
I would have expected the compiler to inline and generate comparable
assembly. Well, seems it didn't.
|
| | |
|
| |
| |
| |
| | |
Seems not to have any performance impact, but still, cleaner this way.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Benchmarks show that MulAssign is quite a bit faster than Mul,
especially since in this case it's mathematically proven that the
multiplication cannot overflow.
Also, removed skipping of leading zeros in long division. With the
switch to multiplication after the first iteration, the chance that
there actually are any leading zeros is on the order of 2^-26.
I think at least. In any case, it's small.
|
| | |
|
| |\
| |/
|/| |
|
| |
| |
| | |
This is just a bare-bone default setup.
|
| |\
| |/
|/| |
|
| | |
|
| |
| |
| |
| |
| |
| | |
As it turns out, the speed gained by lowering the number of digits in
divisor using repeated division is much less than the speed gained by
using multiplication of the dividend instead of division of divisor.
|
| |\
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
In PasswordMaker, the numbers that are fed into long division can only
decrease. Therefore, skipping leading zeros is a rather reasonable
improvement.
|
| |
| |
| |
| |
| |
| | |
There are now 2 features that control the amount of precomputed
constants. They can either be 0, 12, or 256. Most users will likely want
to go with the 12, so this is the default feature.
|
| |\
| |/
|/| |
|
| |
| |
| |
| |
| | |
20 bytes worst case was using 16 bytes.
32 bytes full division was producing a leading zero.
|
| |
| |
| |
| |
| | |
It seems English doesn't use the word potency in this context, but
rather uses power.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The maximum power of the base that can fit into a given data type is
constant. There's no point in computing it at runtime, if we can just
store it in a compile-time constants array.
The code isn't the most beautiful, but that's mostly because Rust const
functions are still a bit limited.
One function was duplicated, because it was easy to get a slow version
to compile in const context, and const context doesn't really care...
|
| |\
| |/
|/| |
|
| |
| |
| |
| | |
It's not perfect, but a much better guess than previously.
|
| |\
| |/
|/| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
The handling of overflows was non-performing before. Now it's performing
and correcting. This lets us skip a less-than check for N-digit numbers,
causing a slight performance improvement.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Speeds up the 20 and 32 byte cases. Has slightly negative impact for 16
byte case.
|
| |
| |
| |
| | |
Just to remove code duplication.
|
| |\
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The previous parameters for benchmarks were based on gut-feeling.
Now each hash-length has 3 benchmarks:
- Typical is a typical user input
- Max Divisions is a full generate_password_part run
- Worst Case is the worst user input possible: Base 2.
|
| | |
|
| |\
| |/
|/| |
|
| |
| |
| |
| |
| | |
Now that work on performance has started, accurate readings are
important.
|
| |
| |
| |
| | |
That's a lot faster than division.
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
As preparation for an eventual rewrite of the base conversion code.
|