Performance optimizations around logging#152
Conversation
|
Started Dbuild - https://jenkins.scala-sbt.org:8592/job/sbt-validator/474/console |
|
The validator has checked the following projects against Scala 2.12,
✅ The result is: SUCCESS |
300792f to
58994cc
Compare
3d508ff to
d9b130d
Compare
|
@eed3si9n Cleaned up and ready for review. |
|
can we revert the string building changes back to the interpolators in 2.12.5, @retronym, given scala/scala#6093? |
eed3si9n
left a comment
There was a problem hiding this comment.
overall LGTM
Do you have some numbers we can quote?
|
No, I'm afraid I don't. I noticed differences in the profiles before and after, but didn't have a good way to measure the reduction in CPU time. I was hoping to collect better numbers for this change (and future ones) by rigging up SBT under JMH using a custom profiler like in: scala/compiler-benchmark#61, but I've been unable to run SBT programattically (as opposed to through its launcher). |
|
@dwijnand Yep, hopefully we'll get the opts into the built-in interpolator. That said, this sort of low level infrastructure code should be written for a wide variety of workloads, which means it is wise to avoid too many temporary objects, so even factoring out methods that are internally efficient with the new |
RunFromSourceMain is my (ongoing) attempt to finding a way to launch sbt without going through the launcher. |
TypeTag[SuccessEvent]used in the frequently calledManagedLogger.success. TheTypeTagitself has a lazy valtpefield that caches theType, so we save some work in creating callingtpe.toStringlater on.StringBuilderused to buffer console output, rather than creating new one for each line.