This is likely because you are running it in some random PWD that doesn't represent a bazel workspace. When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.
Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.
> When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.
It still has a slow startup time, bazel just works around that by using a persistent daemon, so that it is relatively fast after as long as the daemon is running.
Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation.
If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.
I did mean improperly using cached results. It's merely the hardest problem in computer science :)
The sibling suggests this may still be an issue. I'm not surprised—cache invalidation is very difficult to solve, and conservative approximations like tearing down the whole process each time tend to be quite effective.
Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.