Avoid lroundf using, overall 24% speedup for any images

[homm]

If you look to perf report, this only function uses a lot of CPU while it is totally avoidable.

$ perf record python -m timeit -n3 -r10 \
    -s "import pyheif; data = open('./full.norot.heic', 'rb').read()" \
    "im = pyheif.read(data)"

master:

$ taskset 0x1 python -m timeit -n3 -r10 \
    -s "import pyheif; data = open('./full.norot.heic', 'rb').read()" \
    "im = pyheif.read(data)"
3 loops, best of 10: 479 msec per loop

native-rounding:

$ taskset 0x1 python -m timeit -n3 -r10 \
    -s "import pyheif; data = open('./full.norot.heic', 'rb').read()" \
    "im = pyheif.read(data)"
3 loops, best of 10: 386 msec per loop

I'm using taskset 0x1 for more consistent benchmarks results.

[homm]

@farindk any updates?

[homm]

@farindk any thoughts?

[homm]

By the way, this is a regression and was introduced in 1.9.0:

import pyheif
print('# LIBHEIF_VERSION', pyheif.libheif_version())
data = open('/imgs/flat.norot.heic', 'rb').read()
%time for _ in range(10): i = pyheif.read(data)
data = open('/imgs/flat.heic', 'rb').read()
%time for _ in range(10): i = pyheif.read(data)

# LIBHEIF_VERSION 1.7.0
CPU times: user 3.76 s, sys: 596 ms, total: 4.36 s
Wall time: 1.72 s
CPU times: user 5.45 s, sys: 566 ms, total: 6.02 s
Wall time: 3.46 s

# LIBHEIF_VERSION 1.8.0
CPU times: user 3.91 s, sys: 601 ms, total: 4.51 s
Wall time: 1.8 s
CPU times: user 5.67 s, sys: 601 ms, total: 6.27 s
Wall time: 3.55 s

# LIBHEIF_VERSION 1.9.0
CPU times: user 5.4 s, sys: 579 ms, total: 5.98 s
Wall time: 2.19 s
CPU times: user 6.98 s, sys: 629 ms, total: 7.61 s
Wall time: 3.86 s

# LIBHEIF_VERSION 1.10.0
CPU times: user 5.32 s, sys: 594 ms, total: 5.91 s
Wall time: 2.13 s
CPU times: user 7.01 s, sys: 569 ms, total: 7.58 s
Wall time: 3.87 s

# LIBHEIF_VERSION 1.11.0
CPU times: user 5.26 s, sys: 588 ms, total: 5.85 s
Wall time: 2.16 s
CPU times: user 7.08 s, sys: 593 ms, total: 7.67 s
Wall time: 3.95 s

# LIBHEIF_VERSION 1.12.0
CPU times: user 5.17 s, sys: 583 ms, total: 5.75 s
Wall time: 2.12 s
CPU times: user 6.84 s, sys: 591 ms, total: 7.43 s
Wall time: 3.89 s

[farindk]

I used lround() because I wanted to be on the safe side that rounding is done right.
However, looking at https://en.cppreference.com/w/c/language/conversion, it seems that lround() is equivalent to (int)(x+0.5f) at least for positive values.

Thus, I am fine to replace it with a custom, inlined rounding function when it's guaranteed that all values are non-negative.

[kmilos]

I used lround() because I wanted to be on the safe side that rounding is done right. However, looking at https://en.cppreference.com/w/c/language/conversion, it seems that lround() is equivalent to (int)(x+0.5f) at least for positive values.

Thus, I am fine to replace it with a custom, inlined rounding function when it's guaranteed that all values are non-negative.

Should be ok IMHO since one is clipping the incorrectly rounded negative results to 0 in this particular case.

A comment in the code about this might be welcome though.

[farindk]

Thanks. Finally merged :-)