Add build profiling stats

[ryanflorence]

I'd like to track down any build performance hangups before we start hitting build performance issues. We know esbuild is fast, but we have a lot of stuff around it. Getting reports of folks with 100+ routes having dev builds that take 2-4 seconds sometimes.

Long term we want incremental builds in memory (we're actively researching this in #4664, and ironically it's how we did it before we switched to esbuild), but even in that future it would be nice to be able to profile our build and see which functions might become bottlenecks.

I've worked on projects with over 1000 UI routes, we won't be able to support those kinds of apps with a compilation step unless we have data that helps us get there.

Today

Right now we just say how long the build took:

remix watch
# save a file
💿 Rebuilt in 2.8s

Future

We could instrument a handful of functions in the build flow so we get more detailed stats

remix watch --profile
# save a file
💿 Rebuilt in 2.8s
  | 1.2s  virtual modules
  | 1.0s  conventional routes
  | 0.5s  asset imports
  | 0.1s  app config.routes()

I'm just tossing out random things we could measure, the work would mostly be looking through the build flow and deciding the things to actually measure.

Pointless?

Should we just use node's inspector?

node inspect myscript.js
# then open up chrome devtools

We could surface that with:

remix watch --inspect

[dmarkow]

This would be great, we're running a production app with 700+ routes and seeing a fair amount of these performance issues creeping up. I had to do a lot of console.log "profiling" to figure out the cause of #4538, which ultimately shaved 15 seconds off of waiting for remix dev to run.

Would we also want some profiling options on the server runtime separate from the build? I opened #4733 yesterday which has to do with some extra remix overhead in apps with lots of routes that was adding 150-200ms per request in production. Having some profiling on the actual request handler to see how much time is spent on routing, running actions/loaders, generating the response, etc. would be super helpful.

[pcattori]

@sergiodxa : could these issues also be affecting your compile times?

[sergiodxa]

It's highly probably that #4538 is affecting me too, from #4733 description I think this happens on 1.8.0 where Remix uses unstable_createStaticHandler, I haven't noticed runtime perf issues but I haven't profiled too much because my API requests are slower right now.