Re: accumulating projects in kate lead to excessive kate startup time due to git

Hi,

I just want to say this bug can be a little more annoying when using sshfs.
Most of my $dayjob work is done over `sshfs` because the development
environment is just a remote VM with everything setup properly and exposes
an LSP "server" and ssh. Doing many IO on that is rather expensive (hello
git!). I don't think parallelism would make the situation better. Async is
really the best option here. As for "why sshfs and not kio". That's because
of 2 things. First, kio+yubikey = get_a_popup_for_every_io_operation. That
would be rather invasive to fix (maybe adding some middleware/proxy process
that keeps a persistent ssh connection and Kio connects to that?). Also,
there's a little limitation in Kate LSP implementation. When using Kio, it
adds `fish://totally/wrong/path` to the LSP queries and the "server"
doesn't understand it. The $dayjob provided LSP expects either macOS or
Linux home directory paths and the project name (which it assumes is
sshfs-mounted).

On Sun, 19 Jun 2022 at 12:10, Milian Wolff <[email protected]> wrote:

> On Samstag, 18. Juni 2022 14:15:42 CEST Milian Wolff wrote:
> > Hey all,
> >
> > Kate took ~4s to show its main window on my beefy workstation with lots
> of
> > RAM, CPUs and speedy NVME disks. I found this quite odd and wondered
> about
> > the reason so I sat down and profiled it. Perf shows a lot of external
> git
> > processes running sequentially, which I could also replicate with strace:
>
> <snip>
>
> > b) Can we query the git status in parallel for all projects, instead of
> > serially? My machine has 12 cores and 24 threads, and the NVME disk and
> ram
> > should also allow this.
>
> Sorry, hit sent too early...
>
> You can download the perfparser file here:
>
> https://milianw.de/files/kate.slow.startup.perfparser
>
> You can open that in hotspot and then go to the off-CPU time flame graph.
> Basically all of that comes from _really_ slow memory allocations, which
> is a
> first for me. It seems like my system is suffering from some extreme
> slowdowns
> in `int_malloc` - but only in kate. Other applications don't show this
> behavior, and I'm unsure where this comes from... See the excessively slow
> calls to rwsem_down_read_slowpath from _int_malloc, even in the main
> thread.
> If you look at the main thread e.g. there we see ~1s off cpu time from
> _int_realloc by _FcConfigParse::FcStrBufData alone!
>
> I'll try to continue to figure this out
> --
> Milian Wolff
> [email protected]
> http://milianw.de
>
>
>