Tipping the apple cart?

[Alexander Potashev]

вт, 2 июл. 2019 г. в 14:07, Ben Cooksley <bcooksley at kde.org>:
>
> On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt <boud at valdyas.org> wrote:
> > Try opening the changes tab for https://invent.kde.org/kde/krita/merge_requests/54. This makes my browser warn me two or three times that the page is using a lot of CPU and it takes ages before it succeeds.
>
> I opened this just now on my system and it gave me no issues (using
> both Google Chrome and Firefox).
>
> It did take a little while to open (around 20 seconds or so from the
> moment I hit refresh), but that's to be expected given it is a review
> spanning 509 files, with circa 14,500 additions and 7,000 removals,

Hi Ben,

We discussed GitLab performance a few months ago on kde-devel mailing
list, then the discussion stopped. You can re-read it below. I believe
all my statements there are still valid, and I still believe 20
seconds of loading time is very painful.

===== <cut> =====

вс, 24 февр. 2019 г. в 00:47, Ben Cooksley <bcooksley at kde.org>:
>
> On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev
> <aspotashev at gmail.com> wrote:
> >
> > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley <bcooksley at kde.org>:
> > > Based on all of the above we'd like to propose migrating towards
> > > Gitlab. Comments?
> >
> > Hi,
>
> Hi Alexander,
>
> >
> > 1. We migrated from github.com to self-hosted GitLab when I worked
> > full-time in a team of 4 developers. A major drawback we noticed back
> > then was slow page loading when browsing a large diff (e.g. in a merge
> > request). For example, this commit takes around 15 seconds to load:
> > https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533
>
> That commit is massive and is far beyond what would be routine for a
> project to commit, so I think it's quite reasonable for the system to
> take a bit of time to process it.
> Loading that page right now using the web inspector shows it takes
> about 8 seconds to generate, followed by a further 4 seconds to
> download, which doesn't seem unreasonable for 3200 lines of changes,
> plus context, over 187 files - especially given it syntax highlights
> it.

Hi Ben,

The thing is, it's much slower than github - that's why we noticed the
issue. I'm not sure if GitLab is slower than Phabricator, but at least
it tries to feel fast and loads the whole diff incrementally, so that
the first portion is available in less than 1 second.

For reference, here is that same commit in 4 different web UIs:
 - https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533
 - https://github.com/KDE/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533
 - https://phabricator.kde.org/R158:aadd9305b0467fa39e5c84af606c7d9eb1568533?show_all=true
 - https://cgit.kde.org/kdenlive.git/commit/?id=aadd9305b0467fa39e5c84af606c7d9eb1568533
(cgit also has syntax highlighting :))

You are right merge requests as large as this commit are not common, but
 1. Once you have a large merge request, maintainers will probably
spend some days reviewing it and may be open the same diff page many
times, thus multiplying the suffering.
 2. Diffs that are 10x smaller that this one are common, and a 1.5
second loading time (15s / 10 = 1.5s) is still not very comfortable.
 3. A merge request may comprise multiple commits (e.g. 20 commits)
and it's handy to browse/review a squashed diff for the whole merge
request, making the diff 20 times longer that an average commit diff.
Reviewing of multi-commit merge requests is also available on GitHub,
and it's still fast there unlike GitLab.

-- 
Alexander Potashev