Open mgajda opened 1 year ago
I think we could definitely nice
the calls to cabal
etc. For those you need to look in hie-bios
.
I'm not sure about HLS itself. Shouldn't it be the job of the caller to nice
us? In that case that would be the editor.
@michaelpj Since it should be standard practice for editors to call language servers, but this is non-portable.
That is why we have hls-wrapper
executable that does such things as compiling HLS, and starting it.
That is why I think this is the best single point of addition.
Since it should be standard practice for editors to call language servers, but this is non-portable.
I don't understand this objection. Why is it non-portable for the editor to nice us?
That is why we have hls-wrapper executable that does such things as compiling HLS, and starting it.
No, that isn't why we have the wrapper. The wrapper exists to mediate the issue with having multiple HLS binaries for different GHC versions. It's perfectly valid to not use the wrapper and many people don't if they know what HLS they need for a particular environment. So nice
ing in the wrapper is fragile and won't help many of our users.
So you suggest that I should better nice when HLS starts? Ok, will change.
I think that's better. I still don't understand why you think this isn't the client's job?
Time and complexity are most important dimensions in software engineering.
It is more complicated to add to the client.
To push responsibility properly, we would best await for change in the process
and that would take years to implement.
Nice in HLS will likely take an hour of work instead.
Is your enhancement request related to a problem? Please describe.
The language server often compiles for a long time. When compiling, it should stay in the background, and never to delay user interface. So all compilations should be ran with batch priority.
Additionally, the language server itself is asynchronously feeding information to user interface. So it should also decrease its own priority as compared to the calling editor.
Describe the solution you'd like
Decrease priority of language server, and all compilation subprocesses.
Describe alternatives you've considered
Alternative is automatically detecting all GHC/Stack/Cabal processes running, and renice them. It is more complicated, and gives user interfaces a duty to configure it herself. This also delays implementation of the policy, and for a short time the compilation will still be prioritized. Particularly painful, if user wants a speedy parallel compilation on a multicore, and since GHC compiler hogs available RAM.
Additional context
I can add necessary
System.Process.nice
calls before calls ofexecuteProcess
, if the MR would be accepted.