mirror of https://github.com/sbt/sbt.git
6f7a824478
I noticed that sbt 1.3.0 was using more cpu when idling (either at the shell or while waiting for file events) than 1.2.8. This was because I'd reduced a number of timeouts to 2 milliseconds which was causing a thread to keep waking up every 2 milliseconds to poll a queue. I thought that this was cheaper than it actually is and drove the cpu utilization to O(10%) of a cpu on my mac. To address this, I consolidated a number of queues into a single queue in CommandExchange and Continuous. In the CommandExchange case, I reworked CommandChannel to have a register method that passes in a Queue of CommandChannels. Whenever it appends an exec, it adds itself to the queue. CommandExchange can then poll that queue directly and poll the returned CommandChannel for the actual exec. Since the main thread is blocking on this queue, it does not need to frequently wake up and can just poll more or less indefinitely until a message is received. This also reduces average latency compared to older versions of sbt since messages will be processed almost as soon as they are received. The continuous case is slightly more complicated because we are polling from two sources, stdin and FileEventMonitor. In my ideal world, I'd have a reactive api for both of those sources and they would just write events to a shared queue that we could block on. That is nontrivial to implement, so instead I consolidated the FileEventMonitor instances into a single FileEventMonitor. Since there is now only one FileEventMonitor queue, we can block on that queue for 30 milliseconds and the poll stdin. This reduces cpu utilization to O(2%) on my machine while still having reasonably low latency for key input events (the latency of file events should be close to zero since we are usually polling the FileEventMonitor queue when waiting). I actually had a TODO about the FileEventMonitor change that this resolves. |
||
|---|---|---|
| .. | ||
| src | ||
| NOTICE | ||