These are great notes.
My performance improvements were based on the *"time to first byte"* from the
[chrome dev tools](https://developer.chrome.com/devtools/docs/network). *I
attached two files of the before and after based on my tests (using ~200
branches).*
TTFB, while not the best metric for gauging specific functions, it does give an
indication of the perception of latency.
I'm going to re-run the tests and check out the stats.log.
How many branches were your performance tests run with?
Attachment: new.png (69.8 kB; image/png) old.png (69.4 kB; image/png)
---
** [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:** Fri May 08, 2015 08:49 AM 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.
