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

[Milian Wolff]

On Sonntag, 19. Juni 2022 22:14:51 CEST Thiago Macieira wrote:
> On Sunday, 19 June 2022 12:37:21 PDT Milian Wolff wrote:
> > OK, this is apparently totally unrelated to git and kate. Thiago, do you
> > happen to have an insight here maybe? Is it known that using QProcess can
> > really badly influence the runtime behavior of malloc in other threads?
> 
> It could... but it shouldn't be that meaningful. While the child process is
> between fork() and execve(), it is sharing pages with the parent process but
> they are COW. So attempting to allocate memory in the parent process
> *could* cause that very COW to happen.
> 
> If you waitForStarted() and the problem disappears, then this is why. But I
> doubt it will be.
> 
> > Here's a small example to trigger this behavior already:
> > 
> > https://invent.kde.org/-/snippets/2239
> 
> > I have nproc == 24. Let's run this without any external processes:
>
> The example does waitForFinished, so the child process is surely past the
> execve() stage.
> 
> The threading code won't linearly scale. It is entirely thread-safe, but
> you'll see contentions. The entire parent process' virtual address space is
> shared with all children (one per thread) and given that many threads, the
> chances are going to be very high that one thread will malloc() while at
> least one child is still between fork() and execve(), thus causing COW.
> 
> That said, this problem wouldn't be exclusive to memory allocations. The
> simple fact of *running* threads will cause COW on those threads' stacks,
> plus whatever other structures they touch.

Ah, thank you Thiago, that explains it very well.

I wonder, is there a reason why QProcess is not leveraging posix_spawn? That 
should help with this exact problem if I'm not mistaken, see e.g. [1]. But 
then again, this is certainly not an area where I'm proficient in. What's your 
take?

[1]: https://github.com/rtomayko/posix-spawn#benchmarks

Is there maybe a fundamental API limitation that makes that not a viable 
option for usage in QProcess? I could not find any prior discussion on this 
topic yet on the internet. forkfd has the spawnfd function, but it doesn't 
seem to be used by QProcess? Looking at its implementation, it even has this:

```
    assert(!system_has_forkfd());
```

Why is that? I would really like to learn a bit more on this. For starters, I 
expanded my trivial little snippet to get a similar subprocess behavior with 
posix_spawn (obviously lacking error reporting and such), which shows _very_ 
promising behavior on my machine:

https://invent.kde.org/-/snippets/2241

```
perf stat ./slow-malloc --with-subprocess --with-spawn

 Performance counter stats for './slow-malloc --with-subprocess --with-spawn':

          7,291.83 msec task-clock:u              #   11.476 CPUs utilized          
                 0      context-switches:u        #    0.000 /sec                   
                 0      cpu-migrations:u          #    0.000 /sec                   
           680,279      page-faults:u             #   93.293 K/sec                  
    11,531,120,738      cycles:u                  #    1.581 GHz                      
(87.93%)
       757,377,213      stalled-cycles-frontend:u #    6.57% frontend cycles 
idle     (87.40%)
     2,149,619,994      stalled-cycles-backend:u  #   18.64% backend cycles 
idle      (83.65%)
    10,421,791,694      instructions:u            #    0.90  insn per cycle         
                                                  #    0.21  stalled cycles 
per insn  (85.42%)
     2,329,873,392      branches:u                #  319.518 M/sec                    
(85.77%)
        14,154,144      branch-misses:u           #    0.61% of all branches          
(86.83%)

       0.635415286 seconds time elapsed

       2.661544000 seconds user
       2.413737000 seconds sys
```

This is close to the original performance, and roughly 10x faster than using 
QProcess.

Thanks

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20220620/5283e07c/attachment.sig>