Listing branches takes a LONG time

[hramrach]

Description

In a mirror of https://github.com/SUSE/kernel-source.git

listing branches takes a long time

Screenshots

Gitea Version

1.20.3

Can you reproduce the bug on the Gitea demo site?

No

Operating System

Linux (openSUSE 15.5)

Browser Version

Chromium 118.0.5993.70 (openSUSE Build) stable (64-bit)

[lunny]

This has been resolved in v1.21.

[lunny]

I just test it on https://gitea.com/lunny/kernel-source/branches
It's faster than your version but I think it can still be optimized further.

[hramrach]

Yes, that's much faster - about 1500ms

[lunny]

The slow reason is every branch will need to calculate diverged commits numbers with CountDivergingCommits. The result is not cached into database.

[hramrach]

This is general problem with how pages are rendered.

https://gitea.com/lunny/kernel-source/activity/monthly takes 16s
https://gitea.com/lunny/kernel-source/activity/quarterly does not finish, ever.

It looks like the page is rendered on the server and then sent in one go.

This leaves the user with a blank page and timeout.

It appears that most forges would use client-side scripting to load large data.

However, the server could send the page chunked - send the header first, and the data as it is generated, and if needed some extra filler when data takes too long to process to avoid timeouts.

In ancient past it was also possible to load data in a frame which is now deprecated in favor of javascript scripting of loads.

Not sure if static HTML can be used to load another page as an element content.

[lunny]

This is general problem with how pages are rendered.

gitea.com/lunny/kernel-source/activity/monthly takes 16s gitea.com/lunny/kernel-source/activity/quarterly does not finish, ever.

It looks like the page is rendered on the server and then sent in one go.

This leaves the user with a blank page and timeout.

It appears that most forges would use client-side scripting to load large data.

However, the server could send the page chunked - send the header first, and the data as it is generated, and if needed some extra filler when data takes too long to process to avoid timeouts.

In ancient past it was also possible to load data in a frame which is now deprecated in favor of javascript scripting of loads.

Not sure if static HTML can be used to load another page as an element content.

I think this is a new issue from the title. Maybe we could create a new one and close this one.