Rect.clipline() optimization

[itzpr3d4t0r]

This should improve Rect.clipline() performance a bit. Now using fastcall. I get between a 20-30% performance improvement while respecting compat. This could improve further once the Line object is in the geometry module.
Program:

from timeit import repeat

import pygame
from pygame import Rect
pygame.init()

r = Rect(0, 0, 100, 100)

G = globals()
N = 10000
R = 100
T = 5

teststr = """
r.clipline((10, 10, 43, 52))
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()

teststr = """
r.clipline((10, 10), (43, 52))
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()

teststr = """
r.clipline(10, 10, 43, 52)
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()

teststr = """
r.clipline((-123, -222, 1030, 1100))
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()
teststr = """
r.clipline((-123, -222), (1030, 1100))
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()
teststr = """
r.clipline(-123, -222, 1030, 1100)
"""
for _ in range(T):
    print(min(repeat(teststr, globals=G, number=N, repeat=R)))
print()

Results:

CURRENT
0.002615100002003601
0.0025807999991229735
0.0026025000006484333
0.0026103000018338207
0.002587299997685477

0.0025616999992053024
0.002559500000643311
0.00257170000259066
0.0025887999981932808
0.0025588000025891233

0.002294199999596458
0.0022938000001886394
0.002283100002387073
0.002288100000441773
0.0022839999983261805

0.0027561999995668884
0.0027656999991449993
0.002629200000228593
0.002766699999483535
0.0027491000000736676

0.0026986999982909765
0.0027062000008299947
0.002711599998292513
0.002707100000407081
0.0027293999992252793

0.002466500001901295
0.002469299997756025
0.0024465000024065375
0.0024551999995310325
0.0024648999969940633


NEW
0.0021283000023686327
0.0021246000032988377
0.002128899999661371
0.002107899999828078
0.0021397000018623658

0.0021542000031331554
0.0021572999976342544
0.0021763999975519255
0.00213649999932386
0.0021741999953519553

0.0018698999992921017
0.0018481000006431714
0.0018739000006462447
0.001844100006564986
0.0018357000008109026

0.002304800000274554
0.0023109999965527095
0.002189300001191441
0.0022988999990047887
0.0022886000006110407

0.0023344000001088716
0.002318599996215198
0.0022547999978996813
0.0023289000018849038
0.0023317000013776124

0.0019892000054824166
0.0019933000003220513
0.0019625999993877485
0.0019812000027741306
0.0019492999999783933

[Starbuck5]

I read through this, I the args -> fastcall conversion here is very elegant, and doesn't even change the logic significantly.

I was confused though about why you changed the code that does the operation (the code after the argument parsing).

(Before and after)

It was simpler before.

[itzpr3d4t0r]

I was confused though about why you changed the code that does the operation (the code after the argument parsing).

Did that to get rid of that XDECREF. Decref takes time and XDRECREF takes even more, so since the not normalized rect case doesn't happen often i thought to move everything related to rect_copy int there to go as fast as possible in the general case. Nothing major so we could revert if strictly necessary.

[Starbuck5]

Ok, I was wondering what your angle was.

Isn't the difference between XDECREF and DECREF just a NULL check? It doesn't seem worth it to me to make the code longer and harder to read for a single NULL check.

My preference is to take the change out of this PR, because the rest of it looks straightforward to me. My bet is that the vast majority of performance here is coming from FASTCALL. Then in the future if you want to re-add this DECREF change it can be tested and weighed on its own.

[ankith26]

LGTM, thanks for the PR 👍

[Starbuck5]

I like it, faster with less code!