Slow performance

[bschnurr]

Note: if you are reporting a wrong signature of a function or a class in the standard library, then the typeshed tracker is better suited for this report: https://github.com/python/typeshed/issues.

If you have a question about typing or a behavior that you’re seeing in Pyright (as opposed to a bug report or enhancement request), consider posting to the Pyright discussion forum.

Describe the bug
A clear and concise description of what the bug is.

Long type evaluations, over 4 mins for some expressions.

[BG(1)] Long operation: analyzing: d:\source\repos\AirfRANS\dataset.py (289050ms)

To Reproduce
Steps to reproduce the behavior.

clone https://github.com/Extrality/AirfRANS

create a venv
pip install
numpy
pyvista
torch
torch_geometric

open dataset.py

Expected behavior
A clear and concise description of what you expected to happen.

VS Code extension or command-line
Are you running pyright as a VS Code extension or a command-line tool? Which version? You can find the version of the VS Code extension by clicking on the Pyright icon in the extensions panel.

Additional context
Add any other context about the problem here.

LOGS
trace_logs.txt

I tried a 2 month old pyright and still got the same result, so I dont think its a recent regression, most likely just the code is just too complex.

One interesting thing I noticed is that the same line is repeated over and over again in the logs (~30 times)

i ["sampled_points" (dataset) [140:13]] (8762ms)

# Define the inputs and the targets
   pos = sampled_points[:, :2]

[jnooree]

Maybe somewhat related to this issue: I usually see huge performance degradation after installing the pytorch ML framework.

[erictraut]

@jnooree, most perf issues tend to be unrelated to each other. If you have a specific case that you'd like me to look at, please file a separate issue and provide repro instructions.

[erictraut]

I've determined that the exceptionally long analysis time related to the AirfRANS project is related to the nested protocol _NestedSequence defined in numpy. It's a recursive generic protocol definition (i.e. the protocol refers to itself within some of its method signatures). Pyright already has some mitigations in place for recursive protocol definitions, but only in cases where the type arguments for the recursive types match exactly. I'll look for ways to extend this mitigation.

[erictraut]

I've enhanced pyright to perform more aggressive caching of protocol. This helps significantly for nested protocols like in this code sample. With this optimization in place, the analysis time for this file drops from 117s to less than 1s on my machine. This change will be included in the next pyright release.

[erictraut]

This is included in pyright 1.1.317, which I just published. It will also be included in future releases of pylance.