At high thread counts (over 500 or so), the CPU starts to get swamped with p4 calls, and it tends to starve the commit thread and causes it to not get any CPU time at all.
This means p4-fusion downloads all the files at first but it is really slow to digest those files and write them out into the repository while creating a commit. This essentially hangs the process.
High threads counts may even start losing connections because they were left idle for too long and so the Perforce server closed those connections.
p4-fusion should be smarter by giving more affinity to the commit thread and also, manage connections in a way that they are not closed off due to idle time. This means a new threadpool dispatch algorithm might be required.
At high thread counts (over 500 or so), the CPU starts to get swamped with p4 calls, and it tends to starve the commit thread and causes it to not get any CPU time at all.
This means p4-fusion downloads all the files at first but it is really slow to digest those files and write them out into the repository while creating a commit. This essentially hangs the process.
High threads counts may even start losing connections because they were left idle for too long and so the Perforce server closed those connections.
p4-fusion should be smarter by giving more affinity to the commit thread and also, manage connections in a way that they are not closed off due to idle time. This means a new threadpool dispatch algorithm might be required.