Comment by giomasce

Agreed. Many smaller MRs are likely to get the same amount of changes accepted in far less time. Some of the factors include:

* After each change you have to review the whole MR, either because you have to rebuild the context or because it's not obvious how the new changes interact with the old ones. Hopefully the new review won't take as much as the first one, but still it's linear, and the number of changes request is also likely linear in the MR size, so that's already total quadratic.

* More iterations often mean higher review fatigue, at some point I don't want to rehash the same code over and over again, and I tend to postpone bigger MRs in favor of smaller ones.

* Larger MRs are correlated with the author not having a full grasp of what they are doing, and therefore are unable to segment it properly and organize the code properly. Sometimes there are not many alternatives to a large MR, so that's not a hard rule, but there is certainly a decent correlation.

In my experience (admittedly with a company that is not necessarily statistically meaningful) when I began doing code review that helped with my own MRs getting reviewed (and also contibuted positively to performance reviews). First and foremost because it helped me getting a better understanding of the whole code base, not just the parts that I ended up touching; and then, I suppose, also because it made me more trustworthy towards the code maintainer.