You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an Android app developer, Kotlin is my language of choice. Sometimes it is necessary to work on non-Android Kotlin code, for example, in an LSP client tool. KLS is a natural choice for end-end client testing. This end-end client testing can dominate testing time with an apparent minimum of ~3 seconds on a fully loaded, recent iMac, or 20 minutes on an allegedly fast Microsoft Surface device. :-)
It strikes me that KLS has two pain points: 1) process start up, and 2) initialization (processing the initialization rpc request message).
can be minimized by having very, very simple test projects. Something on the order of hello world.
is an avenue worth discussing:
For example, can KLS be started once and sent some sort of "restart" message so that it will interpret the next "initialize" request message as the start of another session? That would avoid the OS startup/shutdown cycle on a per-test basis, hopefully with huge time savings over many tests.
Or can KLS run in the same JVM as the client as a special test mode?
Or should KLS be dropped as the test language server and an uber-simple LS be created that can run in the client JVM?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As an Android app developer, Kotlin is my language of choice. Sometimes it is necessary to work on non-Android Kotlin code, for example, in an LSP client tool. KLS is a natural choice for end-end client testing. This end-end client testing can dominate testing time with an apparent minimum of ~3 seconds on a fully loaded, recent iMac, or 20 minutes on an allegedly fast Microsoft Surface device. :-)
It strikes me that KLS has two pain points: 1) process start up, and 2) initialization (processing the initialization rpc request message).
can be minimized by having very, very simple test projects. Something on the order of hello world.
is an avenue worth discussing:
For example, can KLS be started once and sent some sort of "restart" message so that it will interpret the next "initialize" request message as the start of another session? That would avoid the OS startup/shutdown cycle on a per-test basis, hopefully with huge time savings over many tests.
Or can KLS run in the same JVM as the client as a special test mode?
Or should KLS be dropped as the test language server and an uber-simple LS be created that can run in the client JVM?
Or something else entirely?
Beta Was this translation helpful? Give feedback.
All reactions