Performances
Official benchmarks
The two following graphs show the time it took to run a full install on the GitHub Action runners, every day of the past week, on all major package managers, averaged over multiple runs performed during the day, with each run being itself averaged over multiple installs.
The first graph shows the install time of a Next.js project, and the second one of a Gatsby project. The two solid lines both represent the master branch of Yarn, with the light blue one being Yarn PnP installs, and the dark blue one being Yarn operating under nodeLinker: node-modules. The dotted blue line represents Yarn Classic.
This is only a small subset of the benchmarks we run every three hours on the latest version of each tool. To see all variants of those tests, consult our dedicated Datadog dashboard.
Don't benchmark from pull requests
Or at least use a private repository when doing that.
Yarn enables various security settings when it detects that the running environment is a pull request on a public repository. Amongst others (see Hardened mode), it will by default pull all metadata from the remote registry to confirm they match what's inside the lockfile. This makes installs much slower, but is important to protect our users against lockfile poisoning.
About diminishing returns
Keep in mind when discussing package manager performances that those numbers are very relative. While major and minor releases often come with improvements in terms of install speed, shaving a couple of seconds doesn't have a significant impact - especially when those timings heavily depend on your exact environment (CI platform, cpu count, network speed, ...) and configuration (cache settings).
Whether you plan to use Yarn or another package manager, make sure to not only base your decision on raw speed, but also on more structural reasons: features they each implement, settings they each offer, priorities they each set.