Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

going back to <@U07J10LLW>’s question — I think it makes sense to have a doc about this (simliar to 1:1:1 doc), that we can refer people to

<@U053HNE90>: features, and then performance fixes for features

<@U06A03HV1>: As far as the eager/lazy question goes, it's hard to say without seeing the general model of what's changing here.  One idea though is to throttle the number of eager analysis files, or alternately the number of running workers, based on the total number of analysis files loaded into memory

the other thing about this feature is that it is unnecessary with the jar output patch

It would also be cute to note that highly overlapping targets can be compiled all at the same time in such a scheme

the feature is to avoid classpath lookups in loose directories

Wait, which feature do you mean then?  This specific change to have sbt load analysis lazily?

The tension is that we want to keep as much analysis loaded into memory all the time as possible, without putting too much pressure on the heap, right?

If we're too lazy, we don't load it in and we don't get the benefit if caching

If we're too eager, we put too much pressure on the heap

<@U053HNE90>: #2 from <https://rbcommons.com/s/twitter/r/2178/>

so my "oddly enough" there was due to zinc eagerly loading analysis

(and it looks like i didn't introduce the eager loading of analysis... that's always been a bug in zinc i guess)

Once it's loaded though, it's going to have the same caching semantics that we see now right?

It's not clear to me if this helps in the situation where the analysis really is needed

Then again, the entire transitive graph probably isn't needed most of the time