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

Pants

It consumes &gt;10GB RAM in a python dictionary

And generally starts thrashing the machine

the issue in this case is that you can't request products only for invalid targets

I'm happy to focus on ironing out all isolated issues and just throwing away global

During isolated, I've noticed this block taking a while

```      # Collect classfiles (absolute) that were claimed by sources (relative)
      for source in compile_context.sources:
        classes = computed_classes_by_source.get(source, [])
        add_products_by_target(classes)
        if classes_by_source is not None:
          classes_by_source[source].add_abs_paths(classes_dir, classes)

      # And any that were not claimed by sources (NB: `None` map key.)
      unclaimed_classes = computed_classes_by_source.get(None, [])
      if unclaimed_classes:
        self.context.log.debug(
          items_to_report_element(unclaimed_classes, 'class'),
          ' not claimed by analysis for ',
          str(compile_context.target)
        )
        add_products_by_target(unclaimed_classes)```

It's possible that in the global strategy that was just lost in the noise

On an isolated compile in an unclean workspace

the `fast_relpath` patch i added should have cut that down quite a bit

Pretty sure.  We're working on getting some hard numbers for all of this presently

the other thing is: the `classes_by_source` product is only necessary in a particular magic junit case =(

...where it is trying to convert source files into test classes to pass to the junitrunner

Hm.  If junit isn't scheduled then the product shouldn't be requested, right?

The current engine should be able to at least short circuit when the product isn't needed

That is not universal, and it's certainly not how most devs here work