Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357734 - [server][log] Improve the performance of Git Log
Summary: [server][log] Improve the performance of Git Log
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Git (show other bugs)
Version: 0.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 0.5 M1   Edit
Assignee: Tomasz Zarna CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 343506 357774 358214 370132
Blocks:
  Show dependency tree
 
Reported: 2011-09-15 04:10 EDT by Szymon Brandys CLA
Modified: 2012-03-22 10:58 EDT (History)
3 users (show)

See Also:

Attachments
mylyn/context/zip (3.43 KB, application/octet-stream)
2012-01-09 07:55 EST, Tomasz Zarna CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Szymon Brandys CLA 2011-09-15 04:10:38 EDT 
Orion Git Log supports pages however the implementation does not perform well and timeouts still may occur. This is because even if we are requesting a page a few commits, the server implementation gets the full log (what takes time) and then just cuts out requested commits and returns them.
Comment 1 Tomasz Zarna CLA 2011-09-15 05:57:20 EDT 
This is not going to be as easy as I initially expected. I was aware that JGit porcelain API for git-log is missing params suitable for paging (the reason why Szymon implemented the logic as described in comment 0), but I hoped we can achieve that by using a lower lever API. Unfortunately, even though CGit git-log has params that are useful here (i.e. --skip and --n) they are not available in JGit. The problem here is that both org.eclipse.jgit.pgm.Log and org.eclipse.jgit.api.LogCommand use RevWalk which walks a commit graph. It's an Iterable so I guess the best approach would be to modify the way it returns commits (eg. by providing a org.eclipse.jgit.revwalk.Generator).
Comment 2 Tomasz Zarna CLA 2011-09-15 12:29:48 EDT 
(In reply to comment #0)
> the server implementation gets the full log (what takes time) 

Creating the walker doesn't seem to be time-consuming, it's the walk itself (i.e. calling next()) that may cause timeouts. Having said that, I was quite surprised hearing that even git-logs with few commits[1] can time out. 

[1] those little git log widgets on the Git Status page
Comment 3 Tomasz Zarna CLA 2011-09-26 08:01:33 EDT 
Another way of improving Git Log is caching the result, see bug 339846.
Comment 4 Tomasz Zarna CLA 2011-10-03 05:02:02 EDT 
Fixing bug 343506 and bug 358214 gave the Git Log enough boost, so we can postpone the other two (ie. bug 339846, bug 357774) until 0.4.
Comment 5 Tomasz Zarna CLA 2012-01-09 07:55:35 EST 
Fixed with f94cba36c46d09f0471491a549390231c11011ee and new options for LogCommand (see bug 357774).
Comment 6 Tomasz Zarna CLA 2012-01-09 07:55:55 EST 
Created attachment 209201 [details]
mylyn/context/zip
Comment 7 Tomasz Zarna CLA 2012-02-02 08:13:21 EST 
I'm reopening this one, waiting for a fix for bug 370132 in JGit. For more details see bug 368567.
Comment 8 Tomasz Zarna CLA 2012-03-22 10:58:40 EDT 
Re-applied the fix from comment 5 as 59ef7185dcc4e8fdb38e0aeb987caa8ddb22a7a7