significant pdm sync performance regression in 2.13

[deronnax]

• I have searched the issue tracker and believe that this is not a duplicate.

Steps to reproduce

Have a project with a lot of dependencies, do a time pdm sync with pdm 2.12, and then the same thing with pdm 2.13, with cache disabled for more reliability in the timing. I did a reproducible test case in a public gitlab.com repository that I link below.

Actual behavior

On March 28th, we noticed a huge increase in time for our CI jobs. pdm sync time had gone from ~1m40 to ~5m40. We investigated and found out it was PDM 2.13 which brought this change in installation time. I did a simple minimum reproducible repository for this issue: Pdm Install Slowdown Demonstrator.
PDM 2.12: 1m24 (link to the job)
PDM 2.13: 2m31 (link to the job)

The difference on this reproducible case is much less noticeable than in our CI. I guess that's because in our CI we use network disks (amazon EBS).

I highly suspect #2660 but I have no proof at this moment. I suspect the caching of decompressed wheels put network storages in difficulty ; they are know for struggling with huge amount of small files. We tried 2.13 + --no-cache and it made no difference. I suspect that's because it seems that --no-cache doesn't actually change the behavior introduced in 2.13, it just moves it to /tmp.

PDM cache in not used in the reproducible case because we don't use it either in our CI. We experimented PDM cache in our CI it gave almost no improvement in time. That will be the subject for another issue.

Expected behavior

Back the pdm sync performance of PDM 2.12.

Environment Information

Irrelevant

[frostming]

Hi, thanks for the feedback, that is embarrassing. We will revert that change and make a release. After that, we will do a performance analysis to see how we can improve further.