#6707 Slow commit_browser_data


Sometimes RepoRootController.commit_browser_data is pretty slow. Based on log statements, it looks like the slowness is in the first 2 lines of the method. This is supported by timermiddleware instrumentation which has high timings for svn_lib.log and git_tool._iter_commits_with_refs.next and git_tool.log.next We could consider a max time limit similar to [#6695]


Tickets: #6695


  • Dave Brondsema

    Dave Brondsema - 2013-10-04
    • Milestone: forge-oct-18 --> forge-nov-01
  • Dave Brondsema

    Dave Brondsema - 2013-10-21
    • Milestone: forge-nov-01 --> forge-backlog
  • Anonymous - 2013-11-06

    Originally by: titi_ger

    We have serious problems with this too:

    Currently its more or less completly useless for us :-( .
    ( currently it takes miore than 3 minutes if it works at all )

    I would strongly recommend to only list checkins from the last 3 weeks ( or only a small number ). I believe getting the whole history simply takes too long. And if you make the range what to see selectable for the user too it would be a great benefit! ( look how trac does it: https://sourceforge.net/apps/trac/megaglest/timeline ) .

    And please hurry, we really need something like this ;-) .

  • Anonymous - 2013-11-16

    Originally by: mvejvoda

    Totally agree, the browse commits is completely useless for us because its performance makes it unusable.. a real show stopper to get a view of commit history as there is no other useful view like this one (since you took away using trac for this in allura)

  • Cory Johns - 2014-02-19

    [#7128] fixes this for SVN. For git and mercurial, the History link in the right side of the header should provide all but the visual graph functionality, in a performant fashion, until we can get the graph working for them as well (and hopefully combine History and Commit Browser).



    Tickets: #7128

Log in to post a comment.