search

Gert-dev / php-ide-serenata

Atom IDE package that integrates the Serenata server to provide PHP code assistance
https://serenata.gitlab.io/
Other
275 stars 22 forks source link

Filter file indexing commands based on project configs #520

Closed sjuvonen closed 3 years ago

sjuvonen commented 3 years ago

This patch adds filtering of file index requests based on project configuration prior to dispatching them to the Serenata language server app.

Currently the Atom plugin is sending nonsensical indexing requests to the backend every time e.g. a Symfony PHP app writes to a local log file or flushes caches. This will often lead to completely unnecessary project reindexing and often enough even seemingly endless loops that consume 100 % of CPU time "forever" and forces one to restart the whole Atom editor.

Also in general it is much better for performance to avoid pointless TCP traffic as the Serenata server app seems to be quite heavy considering laptop use, where battery life and heat dissipation are of significant concern.

Gert-dev commented 3 years ago

I see where you are coming from, and am inclined to merge this, but also feel a bit ambiguous, because the server's exclusion logic could theoretically change at any time, after which this client would need to play catch-up; as a case in point, regexes in exclusion patterns are not supported - admittedly, this will result in some more files being uselessly sent to the server, but playing catch-up could lead to erroneous filtering if more invasive changes happen in the future.

On the other hand, I agree that the current situation is far from ideal, and have also found so in the past: clients pass information about changes to the workspace to the server. There is no - unless this changed recently - way in the LSP to filter that information before it is sent, which is why it happens on the server's side. This is indeed unfortunate, because a large amount of files are irrelevant to the server, and this information will still have been sent over the connection anyway. An extra cumbersome example of this is the Symfony service container cache, which consists of PHP files itself. The best the server-side can do (and does) is say "oh, these don't need to be indexed, let's ignore them". On slower disks, or with large folders causing many changes continuously, even this filtering can be slow, which is likely what you - and I also - are experiencing.

As such, I'm going to (carefully) merge this.