The `fsck` operation checks all objects in a repo, so I think it's going to
scale with the size of the repo overall, not just the number of branches. It
seems overkill to me too, with the potential for being slow on big repos. (I
also wonder how `fsck` could be faster than the `is_valid` checks since they'd
both be going through and checking each ref)
I think a try/catch in the loop would be worth trying. I'd say change it from
a list comprehension to a regular loop so you can put the try/catch around just
the `ref.commit.hexsha` bit that triggers the exception).
Igor's suggestion of caching the results is also interesting. As he says,
we're trying to do direct repo access rather than caching in mongo, but it
would be much faster. I'm ok with using mongo storage if we treat it as a
smart cache, not as a definitive datastore that must be populated by the "repo
refresh" logic before repo webpages are usable. For example: the `branches`
property would know how to get the info from the git repo and would cache the
result in mongo and use that cache. Cache invalidation would happen whenever
new changes are pushed. That'd be in the "repo refresh" functions, but would
be fast and simple.
---
** [tickets:#7873] Git branch & tag speedups**
**Status:** in-progress
**Milestone:** unreleased
**Labels:** performance sf-current sf-4
**Created:** Fri Apr 17, 2015 09:23 PM UTC by Dave Brondsema
**Last Updated:** Wed Jun 10, 2015 02:49 PM UTC
**Owner:** Heith Seewald
I saw that git pages on forge-allura.apache.org were slow, so I looked at
stats.log and saw that the sidebar was the slowest part. I did some additional
digging and found 2 specific areas for improvement:
* in `git_main.py` change `default_branch_name` to a `@LazyProperty` since it
is called many times inside a loop in `RepositoryApp.sidebar_menu`
* Since `sidebar_menu` only requests a certain number of branches, pass that
"limit" all the way through to `git_repo.py`'s `branches` method so that
`is_valid()` is only called a minimum number of times needed.
* make sure the default branch logic to put it at the top of the list still
works (e.g. always put it at the top first)
In addition to those changes, generalize and apply the same approach to the
tags. And also check ForgeHg to see if mercurial can benefit the same way.
---
Sent from forge-allura.apache.org because [email protected] is subscribed
to https://forge-allura.apache.org/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
