Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Summary] Go to file (Find files in repo) optimization #20231

Closed
3 tasks done
wxiaoguang opened this issue Jul 4, 2022 · 6 comments
Closed
3 tasks done

[Summary] Go to file (Find files in repo) optimization #20231

wxiaoguang opened this issue Jul 4, 2022 · 6 comments
Labels
type/summary This issue aggregates a bunch of other issues

Comments

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Jul 4, 2022

Follow:

TODO:

@wxiaoguang wxiaoguang added the type/summary This issue aggregates a bunch of other issues label Jul 4, 2022
@lunny
Copy link
Member

lunny commented Jul 4, 2022

For the find files, we have two ways to optimize. One is cache all the file paths, another is to use a backend search rather than frontend search or both.

@lunny
Copy link
Member

lunny commented Jul 4, 2022

Both are not easy, so for 1.17, a configuration to allow users disable should be a quick patch.

@wxiaoguang
Copy link
Contributor Author

wxiaoguang commented Jul 4, 2022

This feature is not the only slow one, and not the most urgent one to be optimized.

There are already a lot of slow handlers in Gitea.

For example, for the same repo:

$ time curl https://gitea.com/.../.../commits/branch/master/..../.... > /dev/null
curl 0.02s user 0.03s system 0% cpu 56.408 total

$ time curl https://gitea.com/.../.../tree-list/branch/master > /dev/null
curl  0.05s user 0.02s system 0% cpu 19.313 total

Update: now the 56s handler has been optimized by 20765. That repo has got commit-graph write --changed-paths (19812 comment).

A new test shows that the gitea.com/.../tree-list/branch/master still needs 19 seconds for the first time, and 6-9 seconds for later. On my side (1G + 512M VPS), the ls-tree is pretty fast:

$ time git ls-tree -r HEAD | wc -l
76950
git ls-tree -r HEAD  0.12s user 0.04s system 87% cpu 0.185 total
wc -l  0.01s user 0.01s system 5% cpu 0.184 total

Before ListEntriesRecursive uses -l (show sizes), it seems that this flag makes the ls-tree much slower. So it could be optimized with a dedicated function to call ls-tree without -l

@wxiaoguang
Copy link
Contributor Author

--> Refactor parseTreeEntries, speed up tree list #21368

@wxiaoguang
Copy link
Contributor Author

--> Use weighted algorithm for string matching when finding files in repo #21370

Then this issue could be closed as completed.

wxiaoguang added a commit that referenced this issue Oct 7, 2022
Close #20315 (fix the panic when parsing invalid input), Speed up #20231 (use ls-tree without size field)

Introduce ListEntriesRecursiveFast (ls-tree without size) and ListEntriesRecursiveWithSize (ls-tree with size)
zeripath pushed a commit that referenced this issue Oct 8, 2022
…#21370)

This PR is for:
* #20231

Now, when a user searches `word`, they always see `/{word}.txt` before
`/{w}e-g{o}t-{r}esult.{d}at`

Demo:

When searching "a", "a.ext" comes first. 

Then when searching "at", the longer matched "template" comes first.

<details>


![image](https://user-images.githubusercontent.com/2114189/194588738-3644d891-956f-40e4-b79b-b97d34265456.png)


![image](https://user-images.githubusercontent.com/2114189/194588797-9b124670-4e1e-4510-a170-780295ed89b8.png)

</details>

This PR also makes the frontend tests could import feature JS files by
introducing `jestSetup.js`

Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: silverwind <me@silverwind.io>
@wxiaoguang
Copy link
Contributor Author

All done

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/summary This issue aggregates a bunch of other issues
Projects
None yet
Development

No branches or pull requests

2 participants