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

Pants

so you get added D times, where D is your depth.

We must be passing all the files and dirs into collect()

when really we only need to pass the root dir

the tarfile library does its own descent into the dir.

So I was profiling some basic `pants` commands (like `./pants goals`) to see what were the constant overheads in launching a `pants` command.  One of the surprising results I encountered was initializing hundreds of `argparse` `ArgumentParser`s (one for each scope, apparently).

the non-idempotence of tarfile.add() strikes me as a bit awkward, I bet most ppl would assume it would not actually add the same file multiple times

I looked at the internals of `pants` parsing and it looks like `pants` does this as a convenience to more easily scope arguments registered using `register`

<@U09S0QZM4>: how long does that take approximately?

It varies from machine to machine but between 150 to 300 ms

<@U09S0QZM4>: ArgumentParser is an implementation detail of the pants option system, yes.

We could instantiate those lazily, only on scopes where we actually have something to parse.

The second hotspot was initializing many backends on startup

There might be a way to do that lazily, too

That was also in the same range (~200 ms)

There was one last hotspot, but I forgot what it was.  I'd have to redo the profiling to remember, but all three hotspots were in roughly the same range

Never mind, I found my notes.  The actual registration of options was the third hot spot and it was the worst one

Also, the upper end of the range was higher.  On one system they were 600ms/600ms/1400ms respectiely

I will try to make it lazy and submit a review board if I can successfully cut down on the startup time