New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Very sluggish autocomplete with PyCall #54131
Comments
Thanks, it's good to know in case this is a regression, but are you just running out of (virtual) memory? Do you see OOM in syslog? I do not... On my 1.12.0-DEV.361 on Linux (with 32 GB) I get no slugginess on the second try:
but then later sluggy, and the first time around sluggy right away. Had to kill julia in both cases and then (in first case) I got:
then next:
The third time it seemed to work though... I also suggest you try PythonCall.jl both should though likely be as (non)sluggy. I installed it, and strangly didn't get latest version: [I could update both to latest, noting was blocking needed deleteing, which is strange, then why not get latest right away...?] Then I (predictably got):
|
Is it also slow for tab completion on julia 1.10? |
No problems with 1.10 |
As in pressing tab on the same partial completion is fast on 1.10, but complete hinting at the same position is slow on 1.12? |
Right--same conditions, different behavior To be clear, this doesn't involve pressing tab; any alpha character typed after opening the paren results in the delay. If the first character after the paren is a left bracket--eg, julia> nn.Sequential( # delay after the next alpha character
julia> nn.Sequential([nn.Linear( # delay after the next alpha character |
What I'm asking for should involve pressing tab in 1.10. To be explicit.. find an alpha char that causes a single autocomplete such that tab complete returns a single result. Let's say that's in 1.10
in 1.12
Do the times in which it takes for |
Yes |
Ok so completing in this case hasn't slowed down. It's just that it's painful on 1.11 because of the hints. A profile would be helpful. |
The stacktrace on abort
suggests it is doing type intersection. |
There is supposed to be a limit in complete_methods! on how many methods to return to preserve performance here (even if a package adds too many methods to a function). Did that get changed or should it be even lower? |
The text was updated successfully, but these errors were encountered: