561: RB takes way too long to load a large diff across many files
- Invalid
- Review Board
| kevin.******@beatpo****** (Google Code) (Is this you? Claim this profile.) | |
| July 30, 2008 |
RB is taking more than fifteen minutes to load a 210K patch in my browser. That patch spans 30 files and deals with changing JOIN ... USING to JOIN ... ON and the associated test SQL files that are used to verify that the changes are valid. Each conversion results in at least three patches - the original versus the updated code, the extraction of the original SQL and the extraction of the updated SQL. As you can imagine, that makes reviewing this change set very difficult for the twenty individuals that need to look at it. If I wanted to try to split the review up, I don't have a way to link reviews together so comments can be aggregated. Frankly, at this point, I'd much rather see something like how Bugzilla reviews are done (https://bugzilla.mozilla.org/attachment.cgi?id=170464&action=edit)
The patch itself isn't too big, so the slowdown is likely due to accessing the files from the repository. Once this is done once, it should be cached for a while. I'm not sure why it would be so slow for you. At VMware, we have a thousand engineers using Review Board for patches up to 4MB in size across about 10 repositories and aren't having the slowdown you're seeing. What cache backend is being used there, and what repository type? Also, how recent is the server? Some time ago we added support for paginating the diffs so that we only dealt with a certain number of files at a time. It should be helping, so we need to find out why it's not.
-
+ NeedInfo
C - Great questions. For now, let's just close this bug then and I'll reopen if it proves to be RB. Thanks :-)
