`phpstan/phpstan` pack resolves with a single thread only

[Byron]

Discussed in #2422

^{Originally posted by homersimpsons February 7, 2026}
Today I gix clone https://github.com/phpstan/phpstan.git and it took ~20 minutes:

❯ gix clone https://github.com/phpstan/phpstan.git
 13:49:18 indexing done 100.7K objects in 850.33s (118.0 objects/s)             
 13:49:18 decompressing done 18.3GB in 850.33s (21.5MB/s)                       
 13:54:35     Resolving done 100.7K objects in 317.26s (317.0 objects/s)        
 13:54:35      Decoding done 160.2GB in 317.27s (504.9MB/s)                     
 13:54:35 writing index file done 3.3MB in 0.03s (130.2MB/s)                    
 13:54:35  create index file done 100.7K objects in 1167.72s (86.0 objects/s)   
 13:54:36          read pack done 6.9GB in 1167.94s (5.9MB/s)                   
 13:54:36           checkout done 786.0 files in 0.13s (6.0K files/s)           
 13:54:36            writing done 67.8MB in 0.13s (521.7MB/s)   

(note that was on wifi and around 5MB/s for "half" of the download and then 30MB/s for the other "half")

I hence ran git clone https://github.com/phpstan/phpstan.git to compare the results:

❯ time git clone https://github.com/phpstan/phpstan.git
Cloning into 'phpstan'...
remote: Enumerating objects: 100714, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 100714 (delta 3), reused 8 (delta 3), pack-reused 100699 (from 1)
Receiving objects: 100% (100714/100714), 6.43 GiB | 21.10 MiB/s, done.
Resolving deltas: 100% (66589/66589), done.

real	7m6.327s
user	19m56.695s
sys	0m56.571s

[Byron]

Thanks so much for sharing!

This is a wonderful example for gitoxide having a disadvantage due to the way it parallelises. It walks the tree of pack deltas with as many threads as possible, but not every tree parallelises equally. Few files with long changes are a way to starve threads. There is work-stealing, but it's quite primitive I suppose and doesn't work well here.

During the resolution step, gix just gets to use a single core, taking up to 14.5GB of real memory!

❯ /usr/bin/time -lp gix clone https://github.com/phpstan/phpstan.git
 19:23:37 indexing done 100.7k objects in 164.68s (611.0 objects/s)
 19:23:37 decompressing done 18.3GB in 164.68s (110.8MB/s)
 19:25:19     Resolving done 100.7k objects in 102.21s (985.0 objects/s)
 19:25:19      Decoding done 160.2GB in 102.21s (1.6GB/s)
 19:25:19 writing index file done 3.3MB in 0.01s (445.1MB/s)
 19:25:19  create index file done 100.7k objects in 266.95s (377.0 objects/s)
 19:25:19          read pack done 6.9GB in 266.97s (25.9MB/s)
 19:25:20           checkout done 786.0 files in 0.08s (10.2k files/s)
 19:25:20            writing done 67.8MB in 0.08s (881.8MB/s)
[..]
real 267.80
user 379.40
sys 29.91
         15568224256  maximum resident set size
                   0  average shared memory size
                   0  average unshared data size
                   0  average unshared stack size
             2448391  page reclaims
               10061  page faults
                   0  swaps
                   0  block input operations
                   0  block output operations
                1348  messages sent
            10355725  messages received
                   0  signals received
               99571  voluntary context switches
             6332985  involuntary context switches
       6297819465898  instructions retired
       1517711318974  cycles elapsed
         13283690616  peak memory footprint

That truly is a worst case and it's a great test-case for parallelisation improvements.