✨ Faster uuid generation

[ff137]

Next up on the list of improvements that nobody asked for :-) faster uuid generation!

I noticed in the StorageRecord class that a new uuid4 is always generated when one isn't provided. This seemed important. So I wondered what is the fastest way to generate a uuid, and unsurprisingly, there is a python-rust binding that claims to be 10x faster than the default python uuid library.

https://github.com/aminalaee/uuid-utils

I verified the benchmarks with a timeit script, comparing that with another rust-binding library fastuuid:

import timeit
import uuid

from fastuuid import uuid4 as fastuuid4
from uuid_utils import uuid4 as utiluuid4


def uuid4_hex():
    return uuid.uuid4().hex


def fastuuid4_hex():
    return fastuuid4().hex


def utiluuid4_hex():
    return utiluuid4().hex


if __name__ == "__main__":
    number = 1000000  # Number of executions for timeit

    uuid4_time = timeit.timeit("uuid4_hex()", globals=globals(), number=number)
    print(f"uuid4_hex().hex: {uuid4_time:.6f} seconds")

    fastuuid4_time = timeit.timeit("fastuuid4_hex()", globals=globals(), number=number)
    print(f"fastuuid4().hex: {fastuuid4_time:.6f} seconds")

    utiluuid4_hex_time = timeit.timeit(
        "utiluuid4_hex()", globals=globals(), number=number
    )
    print(f"utiluuid4_hex().hex: {utiluuid4_hex_time:.6f} seconds")

My results:

uuid4_hex().hex: 2.518658 seconds
fastuuid4().hex: 1.306156 seconds
utiluuid4_hex().hex: 0.280322 seconds

0.28 seconds vs 2.5 seconds. That's 9 StorageRecords that can now be generated in the time that it previously took for 1!

It's a drop-in replacement. If maintainers like it as well, maybe it'll make ACA-Py a lil bit faster :-)

[jamshale]

Seems like a straightforward improvement 👍

Only possible concern would be that the library is owned by an individual instead of python, but I think the improvements are definitely worth switching.

[jamshale]

FYI. Sonarcloud is working correctly now. I think it's just reporting stuff that already existed in the changed files. We should still fix or ignore issues if they aren't a lot of effort.

The integration test fail we can ignore. It's a flaky test that seems to be flakier recently.

[jamshale]

@dbluhm @ianco Any opinions on this?

[ff137]

not sure of the mean/variance for the integration tests, but it seems to consistently shave some time off

[jamshale]

Recently merged a new workflow for the integration tests. The usually take just over 40mins and the latest run was a bit faster. They can vary a few minutes depending on if other integration tests are running at the same time. This latest run did seem a bit quicker though.

[dbluhm]

Seems like a low effort way to speed things up. If there ever is a problem with the library, seems like a find and replace across the project would really be all that was necessary to switch back so seems like pretty low risk to add in.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.9% Coverage on New Code
2.4% Duplication on New Code

See analysis details on SonarCloud