bytes.fromhex is much slower than binascii.a2b_hex

[dgrisby]

Bug report

Bug description:

I was looking at modernising some old code that uses binascii.a2b_hex, and I was surprised to find that bytes.fromhex() is a lot slower:

>>> timeit.timeit('bytes.fromhex("abcd1234abcd1234")', number=10000000)
1.0542256180197
>>> timeit.timeit('binascii.a2b_hex("abcd1234abcd1234")', 'import binascii', number=10000000)
0.4072963949292898

I thought maybe it was a difference in the lookup of the bytes classmethod vs the module lookup. It appears that it is, to some extent, but not completely:

>>> timeit.timeit('fromhex("abcd1234abcd1234")', 'fromhex=bytes.fromhex', number=10000000)
0.6133267850382254
>>> timeit.timeit('a2b_hex("abcd1234abcd1234")', 'from binascii import a2b_hex', number=10000000)
0.3788172130007297

Of course, all these times are extremely small, so it probably does not matter in most situations, but still, I found it surprising.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[picnixz]

binascii.a2b_hex and bytes.fromhex do not do the same work. The docs say for a2b_hex:

hexstr must contain an even number of hexadecimal digits (which can be upper or lower case)
Similar functionality (accepting only text string arguments, but more liberal towards whitespace) is also accessible using the bytes.fromhex() class method.

So, I guess those additional checks are the reason why it's slower. I can investigate tomorrow though.

[picnixz]

I can confirm that bytes.fromhex is much slower, even on a PGO build:

$ ./python -m pyperf timeit -s 'fromhex=bytes.fromhex' 'fromhex("abcd1234abcd1234")'
.....................
Mean +- std dev: 52.1 ns +- 0.5 ns
$ ./python -m pyperf timeit -s 'from binascii import a2b_hex as fromhex' 'fromhex("abcd1234abcd1234")'
.....................
Mean +- std dev: 18.9 ns +- 0.7 ns

I'll see if we can do something to improve the performance though but I doubt it will be possible. However, we can indicate that unhexlify is a faster but stricter alternative.

[picnixz]

Ok, I've looked at the code and I don't think we can make it easily faster, unless we duplicate the code for binascii.unhexlify and have a fast path when the string does not contain any space (this is the additional feature that bytes.fromhex supports). However, for this fast path, we must first scan the entire string and check if there's a space using memchr. For small strings, maybe there will be some improvements.

Now, I guess that most of the time, inputs to bytes.fromhex do not contain spaces but this is just me guessing. Sometimes, hexstrings contain spaces just for the sake of clarity, but sometimes not. However, I usually worked with hexadecimal strings that do not have spaces. So maybe we could speed-up that case (again, at the cost of looking up for a space).

@vstinner The current code for bytes.fromhex uses the PyBytesWriter API. Do we gain much if we instead use raw allocation and manually fill the buffer, and then call PyBytes_FromStringAndSize ourselves? (namely, we would by-pass some checks and some ifs but I don't know if it's worth it).

[vstinner]

@vstinner The current code for bytes.fromhex uses the PyBytesWriter API. Do we gain much if we instead use raw allocation and manually fill the buffer, and then call PyBytes_FromStringAndSize ourselves?

I have no idea. Someone has to try and run a benchmark.

[plashchynski]

@picnixz @dgrisby the big difference in your experiments seems to stem from class method vs. module function call overhead. A class method invocation is slower, involves more lookups, checks, and allocations. To compare the actual performance of these two functions, you should benchmark them with bigger input and less invocations. So it spends more time in the function itself, rather than outside of it. So the invocation time makes less impact on the overall time. Hope it makes sense.

Here's my experiment and results:

# with small input (16 chars:
./python.exe -m timeit -n 10000000 -s 'import binascii; input="0123456789abcdef"' 'binascii.a2b_hex(input)'
10000000 loops, best of 5: 28.8 nsec per loop

./python.exe -m timeit -n 10000000 -s 'input="0123456789abcdef"' 'bytes.fromhex(input)'
10000000 loops, best of 5: 73.7 nsec per loop

bytes.fromhex 155.90% slower.

With larger input (1600 chars):

./python.exe -m timeit -n 100000 -s 'import binascii; input="0123456789abcdef" * 100' 'binascii.a2b_hex(input)'
100000 loops, best of 5: 571 nsec per loop

./python.exe -m timeit -n 100000 -s 'input="0123456789abcdef" * 100' 'bytes.fromhex(input)'
100000 loops, best of 5: 647 nsec per loop

bytes.fromhex only 13.31% slower.

[picnixz]

Oh thanks for that. I'll also try to check the differences between those two by simply benchmarking the two algorithms instead. It's a bit sad that calling a classmethod is a bit slower in this case :( (and significantly drops performance). If isolated algorithms also behave similarly, then I don't think we can do anything in particular.

[vstinner]

If you get the function in the timeit setup statement, the difference is lower:

$ python -m timeit -n 10000000 -s 'import binascii; input="0123456789abcdef"; a2b_hex=binascii.a2b_hex' 'a2b_hex(input)'
10000000 loops, best of 5: 42.3 nsec per loop
$ python -m timeit -n 10000000 -s 'input="0123456789abcdef"; fromhex=bytes.fromhex' 'fromhex(input)'
10000000 loops, best of 5: 66.6 nsec per loop

[picnixz]

On my machine, the difference is still quite significant (PGO+LTO build):

./python -m timeit -s 's = "abcd1234abcd1234"; fromhex=bytes.fromhex' 'fromhex(s)'
5000000 loops, best of 5: 51 nsec per loop
./python -m timeit -s 'import binascii; s = "abcd1234abcd1234"; fromhex=binascii.a2b_hex' 'fromhex(s)'
20000000 loops, best of 5: 17.9 nsec per loop

In my case, it's almost a 3x difference, while in your case it's a 1.5x diff. So there might be something at play (or is it just because of my laptop specs?) I didn't have time yet to investigate but I'll try to do it by the end of the week.