Completions sometimes take a long time to load + general huge response times

[Fleeym]

Verified on latest main

• I have confirmed this bug still occurs when built from the latest main branch.

PHPantom version / commit

0.10.0

Installation method

Pre-built binary from GitHub Releases

Operating system

Linux x86_64

Editor

Neovim

Bug description

Hello!

First of all, huge thanks for creating this LSP, it has very high potential and is extremely useful.

Sadly, I've been running into some performance issues while using it: completions take a very long time to load, seemingly at random times (sometimes they pop up instantly, sometimes they take up to 30 seconds to load). This seems to slow down the entire LSP, as other features of it (hovering / signature help) are also slowing down while this is happening.

I've also ran into one panic, which happened when using goto definition (trace below).

My setup:

• Lazyvim with a few custom additions (neovim v0.12.5)
• My processor is an i7-8650U (could be a bottleneck? maybe the project I'm working on is too big for it, though I've seen at most 30-40% cpu usage when the 'freezes' were happening)
• Linux Mint 22.3

I cannot provide any code snippets (NDAs and all that). The issues above appear on a pretty large Laravel project, that uses the laravel-modules package. But if you can point me to any tools you usually use to profile the LSP, I can do the tests myself no problem.

Sorry again for not having that much info, I'll provide anything else you need if I can share it.

Steps to reproduce

No exact steps here, the slowdowns happen seemingly at random, but the common trigger is always waiting for completions.

Error output or panic trace

Panic trace for goto definition. I'll try to get a trace with more symbols, but this is what I have for now.

thread 'main' (375446) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tower-lsp-0.20.0/src/service/client/pending.rs:35:32:
receiver already dropped: Response { jsonrpc: Version, result: Null, id: Number(6) }
stack backtrace:
   0:     0x79013173e7a9 - <<std[1872964b1103b53d]::sys::backtrace::BacktraceLock>::print::DisplayBacktrace as core[57bcf5bae857821d]::fmt::Display>::fmt
   1:     0x79013036db5a - core[57bcf5bae857821d]::fmt::write
   2:     0x790131747796 - <std[1872964b1103b53d]::sys::stdio::unix::Stderr as std[1872964b1103b53d]::io::Write>::write_fmt
   3:     0x79013171806a - std[1872964b1103b53d]::panicking::default_hook::{closure#0}
   4:     0x790131735071 - std[1872964b1103b53d]::panicking::default_hook
   5:     0x79013173526b - std[1872964b1103b53d]::panicking::panic_with_hook
   6:     0x790131718132 - std[1872964b1103b53d]::panicking::panic_handler::{closure#0}
   7:     0x79013170d4d9 - std[1872964b1103b53d]::sys::backtrace::__rust_end_short_backtrace::<std[1872964b1103b53d]::panicking::panic_handler::{closure#0}, !>
   8:     0x79013171d3ad - __rustc[6ef78fba13ac776c]::rust_begin_unwind
   9:     0x79013027d7dc - core[57bcf5bae857821d]::panicking::panic_fmt
  10:     0x79013027d5b2 - core[57bcf5bae857821d]::result::unwrap_failed
  11:     0x790131797953 - <tower_lsp[460b5a2d41af307e]::service::client::pending::Pending>::insert
  12:     0x790131150222 - <futures_util[3be4a4cf5a3952d6]::future::poll_fn::PollFn<<tower_lsp[460b5a2d41af307e]::transport::Server<tokio[d73842c4d2753376]::io::stdin::Stdin, tokio[d73842c4d2753376]::io::stdout::Stdout>>::serve<tower_lsp[460b5a2d41af307e]::service::LspService<phpantom_lsp[5530c7a5b96b1cd1]::Backend>>::{closure#0}::{closure#6}> as core[57bcf5bae857821d]::future::future::Future>::poll
  13:     0x79013116d700 - phpantom_lsp[251b6d0e9ba05c9]::async_main::{closure#0}
  14:     0x790131161eaa - <tokio[d73842c4d2753376]::runtime::park::CachedParkThread>::block_on::<phpantom_lsp[251b6d0e9ba05c9]::async_main::{closure#0}>
  15:     0x7901310dd153 - <tokio[d73842c4d2753376]::runtime::runtime::Runtime>::block_on::<phpantom_lsp[251b6d0e9ba05c9]::async_main::{closure#0}>
  16:     0x79013114e92f - phpantom_lsp[251b6d0e9ba05c9]::main
  17:     0x7901311217f3 - std[1872964b1103b53d]::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  18:     0x79013118e849 - std[1872964b1103b53d]::rt::lang_start::<()>::{closure#0}
  19:     0x7901317335fd - std[1872964b1103b53d]::rt::lang_start_internal
  20:     0x7901311616c5 - main

.phpantom.toml

[indexing]
strategy = "full"

[phpstan]
command = ""

[phpcs]
command = ""

Additional context

No response

[eric-hansen]

I reported something similar in #384 , so far the triaging has been to look at the output of phpantom_lsp analyze -vv . (and/or specific files if you know the ones causing issues).

But, I think the issue is the same having seen your issue. Because the code base I'm working on as well is large with the modules concept (just not with that package in use). Where as if I try phpantom on a standard set up (albeit also smaller in size/complexity), phpantom is instant.

I don't personally have access to a large standard-setup Laravel project though to see if it's the project size, or non-conventional structure (e.g., modules).

[ombimo]

i'm using windows, vs code also sometime get this issue

[Fleeym]

I reported something similar in #384 , so far the triaging has been to look at the output of phpantom_lsp analyze -vv . (and/or specific files if you know the ones causing issues).

Found one specific controller that has about 3000 lines which takes about 40-70 seconds to analyze, so I'm guessing the slowdown is caused by that file. Other files resolve somewhat quickly, at most 15 seconds for a few specific files.

I tried to disable [laravel.schema] and [laravel.migrations], but it had no effect on the analysis.

[AJenbo]

have you tested latest main, I think it's already solved there, else if you can share the offending code that would be helpful, I already tested it with files that are 4500 lines which isn't an issue so it's not size alone