<div dir="ltr"><div><span class="gmail-im"><div>>> Another
 point that requires extra build time for Krita is an inappropriate 
timeout on 100 minutes. A lot of our windows builds are terminated at 
around 95% completion because of this timeout, so we have to rerun them 
and, effectively, consume more and more CI time.</div><div>>Have you got a list of these so I can have a look to see if the timeout is set too low?</div></span></div><div><br></div><div>As far as I can tell the jobs in this MR are hugely affected:</div><div><br></div><div><a href="https://invent.kde.org/graphics/krita/-/merge_requests/2386">https://invent.kde.org/graphics/krita/-/merge_requests/2386</a></div><div><br></div><div>At least two jobs were killed by the timeout, so that we had to restart them.</div><div><br></div><div>As far as I can tell, a normal build of Krita on CI's Windows (with ccache, tests and all) takes about 40-50 minutes. But in moments of high workload on builders the time increases up to "more than 100 minutes". <br></div><div><br></div><div>Just for the sake of comparison, the normal build of Krita on Linux (with ccache, tests and all) takes about 6 minutes. <br></div><div><br></div><div>On Windows ccache is not used for moc-compilations, which take most of the build time.</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Apr 22, 2025 at 1:44 PM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com">dimula73@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> This is probably at least in part due to Windows on Docker having 
extremely poor file system performance even vs. straight NTFS (which 
isn't great to begin with).</div><div><br></div><div>Well, Krita builds on a normal Windows system are also quite slow (at least much slower than on Linux). Though they are still much faster than on CI (about x3-x4 times faster than on CI).</div><div><br></div><div>> Hi, sorry for stupid question, but would it be possible/benefittable to move builds to Linux docker + wine?</div><div><br></div><div>Technically, we could even use the cross-compiler to build that. Our toolchain (llvm-mingw) supports that. Though it would mean one more platform to support, which we cannot afford right now human-resource-wise.</div><div><br></div><div>Theoretically, if we could build the thing in a cross-compiler in WSL2, that could probably help. Then we could entirely drop the native Windows build support. Sounds crazy and error-prone though :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 22, 2025 at 1:13 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Apr 22, 2025 at 10:53 PM Maciej Jesionowski <<a href="mailto:yavnrh@gmail.com" target="_blank">yavnrh@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Yes, that is a full clean build after the build directory is configured from scratch. The dependencies are prepared before that, and this is just the time to run ninja which lists 4900 build steps or so (I can't remember). I mean, the build isn't exactly very fast even on a reasonably high-end system, so I'm not all too surprised that CI is doing worse.</div><div dir="ltr">But I'm sure your concerns are valid too. I noticed Docker can be very slow if the host OS is mismatched with the container OS (although I don't know the details of your setup and it's probably not that here).</div></div></blockquote><div><br></div><div>Docker on Windows uses a Hyper-V virtual machine when there is a mismatch if you are using Windows 10 or Windows Server 2019 yes. On Windows 11 or Server 2022 that is no longer the case as Microsoft put in place syscall interface stability that did not previously exist (much like the Linux kernel syscall compatibility promise) meaning you can run older Windows userspace components against newer kernels. It does require using a Windows 11 / Server 2022 userspace though as a minimum version.</div><div><br></div><div>You do not want it using a Hyper-V virtual machine as the performance is not only abysmal but you end up in memory management pain land very fast - the environment is basically unsuitable for compiling code.</div><div><br></div><div>Our systems make use of Server 2022 for that very reason (Windows 11 did not exist at the time these systems were being implemented)</div><div><br></div><div>Please note that CI runs unit tests as well - which would likely lengthen your runtime by a bit.</div><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 22, 2025 at 12:51 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Apr 22, 2025 at 10:44 PM Konstantin Kharlamov <<a href="mailto:Hi-Angel@yandex.ru" target="_blank">Hi-Angel@yandex.ru</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2025-04-22 at 07:15 +1200, Ben Cooksley wrote:<br>
> On Tue, Apr 22, 2025 at 5:57 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>><br>
> wrote:<br>
> > Hi, Ben!<br>
> > <br>
> <br>
> <br>
> Hey Dmitry,<br>
>  <br>
> > <br>
> > As for Krita, most of CI time is spent on the Windows pipeline,<br>
> > which build extremely slowly due to done obscure filesystem issues<br>
> > (searching includes is extremely slow). I personally don't know how<br>
> > to fix it. I tried: 1) PCH builds, 2) relative includes, 3) split<br>
> > debug info (dwo). The only solution left is to rewrite a huge<br>
> > portion of Krita to reduce amount of includes. Which is, obviously,<br>
> > not an option atm.<br>
> > <br>
> <br>
> <br>
> This is probably at least in part due to Windows on Docker having<br>
> extremely poor file system performance even vs. straight NTFS (which<br>
> isn't great to begin with).<br>
> That will be fixed by VM based CI (progress update - I have most of<br>
> the tool that will manage the underlying base images written now,<br>
> just need to finish the VM provisioning part and give it some serious<br>
> testing)<br>
<br>
Hi, sorry for stupid question, but would it be possible/benefittable to<br>
move builds to Linux docker + wine?<br></blockquote><div><br></div><div>The vast majority of KDE software is built using MSVC (due to the need for QtWebEngine, which is only supported using MSVC on Windows - MingW and co need not apply) which is not supported by Wine (or at least not very well).</div><div><br></div><div>Cheers,</div><div>Ben</div><div> </div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div>