<table><tr><td style="">broulik updated this revision to Diff 23616.<br />broulik retitled this revision from "[RunnerManager] Use QThread::idealThreadCount() instead of going through Solid" to "[RunnerManager] Don't mess with ThreadWeaver thread count".<br />broulik edited the summary of this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-6qukgpqbmzrr5qi/" rel="noreferrer">(Show Details)</a><br />broulik edited the test plan for this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-xyrlwa2c4x4vfbm/" rel="noreferrer">(Show Details)</a>
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D9240" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>CHANGES TO REVISION SUMMARY</strong><div><div style="white-space: pre-wrap; color: #74777D;">We query Solid for processors causing a ton of processing to be done just to get the number of CPUs and then some magic math to determin the thread count. <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">Just use `QThread::idealThreadCount()` for simplicity</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">ThreadWeaver already does everything for us at significantly less performance penalty</span>.</div></div></div><br /><div><strong>CHANGES TO TEST PLAN</strong><div><div style="white-space: pre-wrap; color: #74777D;">It spent 30ms doing this on startup, now it's like 0.05ms<br />
<br />
<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">The previous code would assign my quadcore machine that is not hyper-threading capable 8 threads, now it gets 4 instead</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">ThreadWeaver has essentially the same logic already</span>. I <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">do have the feeling that occasionally the baloo runner blocks the calculator but we need to observe whether this patch makes performance worse but from random testing it doesn't seem like a big deal.</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">just set the cap to be /2 of it to keep the old behavior (which I don't know the reason for)</span></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R308 KRunner</div></div></div><br /><div><strong>CHANGES SINCE LAST UPDATE</strong><div><a href="https://phabricator.kde.org/D9240?vs=23613&id=23616" rel="noreferrer">https://phabricator.kde.org/D9240?vs=23613&id=23616</a></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D9240" rel="noreferrer">https://phabricator.kde.org/D9240</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>CMakeLists.txt<br />
src/CMakeLists.txt<br />
src/runnermanager.cpp</div></div></div><br /><div><strong>To: </strong>broulik, Plasma, Frameworks<br /><strong>Cc: </strong>sitter, davidedmundson, plasma-devel, Frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>