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

[Waqar Ahmed]

The problem with anon sessions that I face currently :

- I want to work on a project Y, I open it
- Later, I want to open another folder in Kate for a moment in a separate
instance, I do kate -n XXX. Kate opens with both projects loaded. This is
not obvious, and one only starts to realize that things are not working
well till you have a lot of projects opened. This affects a lot of features
such as quick open, search etc.

So basically, opening a folder temporarily is now an annoyance as it is not
temporary anymore. One has to remember to close it or kate just keeps
accumulating them silently.

If this was trivial, it would have been okay, but it's not and it breaks
the usecase I mentioned above.



On Sat, Jun 18, 2022, 7:33 PM Christoph Cullmann (cullmann.io) <
christoph at cullmann.io> wrote:

> On 2022-06-18 14:38, Waqar Ahmed wrote:
> > This is a result of a recent feature we added, i.e., a project is
> > saved when you close Kate, and restored when you reopen.
> >
> > This is okay if one uses named sessions. Named sessions need to be
> > opened explicitly. However, for anon sessions, this was a bad idea and
> > is a constant annoyance.
> >
> > It's fixed in a way that we added an option to disable project
> > restoration(upcoming release). But I think for anon sessions projects
> > should never be stored in the first place.
>
> Hi,
>
> yes, I added that option to disable it for that reason.
>
> Not sure about the anon session, we store there other stuff, too.
>
> But it would make sense to try to optimize the behavior,
> the project loading itself should be async, does the GitWidget
> trigger the sync git calls?
>
> Greetings
> Christoph
>
> >
> > Waqar
> >
> > On Sat, Jun 18, 2022, 5:16 PM Milian Wolff <mail at milianw.de> 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:
> >>
> >> ```
> >> $ strace -o kate.process.log -f --timestamps -e process kate
> >> $ grep -E "execve.*git" kate.process.log  | wc
> >> 159
> >> ```
> >>
> >> See also: https://invent.kde.org/-/snippets/2234
> >>
> >> The reason, it turns out, was that my kate accumulated a lot of
> >> projects, and
> >> all of them got queried for their git status.
> >>
> >> I hope that you all agree that this isn't acceptable. The question
> >> now becomes
> >> how to resolve this:
> >>
> >> a) I never knowingly opened a project in kate, this is all done
> >> automatically
> >> in the background. Is it expected that I should manually cleanup the
> >> project
> >> list then? Or can this be done automatically, e.g. by marking
> >> projects as
> >> unused after some time when we don't open a file in them in the last
> >> week or
> >> something like that?
> >>
> >> 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.
> >>
> >> Thanks
> >>
> >> PS: For now, I manually closed all projects and now have a fast kate
> >> startup
> >> once again.
> >>
> >> --
> >> Milian Wolff
> >> mail at milianw.de
> >> http://milianw.de
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20220618/121efaa1/attachment-0001.htm>