Folder jumping

[sapk]

Simple implemation with the adding in git-module (gogs/git-module#7) for implementing #1149

Certainly not the best implementation in term of efficiency.

[sapk]

Maybe a better choice could be to edit the TreeEntry struct and a JumpedFolder attribute relink the treeentry to the pointing file. In this case the treeEntry would reflect the real pointed file and not the folder. It could also limite the calculation to one time. But doing so maybe break other things ...

[saboya]

I tested this in my local install, latest master + this merge. It worked fine, but the performance impact was huge, loading times went up A LOT.

Gogs version: 0.9.8.0312 (+ merge)
Go version: 1.6
OS: FreeBSD 10.1 amd64

[sapk]

I rebase code since it was base on old version and i did some measures. (done with sqlite for db and gogs as repo with some folders to jump, Go version: 1.6)

Before Rebase :
Gogs Version: 0.9.1.0306 Page: 740ms Template: 10ms
Gogs Version (with PR): 0.9.1.0306 Page: 1119ms Template: 14ms

After rebase :
Gogs Version: 0.9.12.0316 Page: 725ms Template: 4ms
Gogs Version (with PR): 0.9.12.0316 Page: 1011ms Template: 4ms

[xor-gate]

Very nice 👍

[mhartkorn]

I find the performance impact of the current solution very high. On a small Java project (3 MB code) the response times went from 270ms to 4200ms. Java projects often have a lot of empty folders because of the package names and this sums up to a lot of loops in the code.

Edit: "Empty" as in "single-entry".

[xor-gate]

@mhartkorn you are right on this, gogs would benefit from aggresive caching at a few places. On our KVM hosted gogs even loading the mainpage takes ~1 second for rendering.

[mhartkorn]

@xor-gate In theory gogs supports redis and memcached but they don't seem to be used at all. But even if gogs was able to use redis for folder structures, a 4 second page load for every single folder in a repository for people that don't use redis is too long to be considered useful in my opinion. Maybe this feature can be an option.

[xor-gate]

People could benefit if in-memory cache works for this long operations. IMHO 4 seconds is crazy for a repo of 3 megabyte. Seems a little performance regression here probably. Even when the disk cache is not warmed up it should not take 4 seconds.

[unknwon]

Just a note Gogs has unified cache interface, it does not matter you use in-memory, redis or memcache.