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. ThreadWeaver already does everything for us at significantly less performance penalty.
Details
Details
- Reviewers
davidedmundson sitter - Group Reviewers
Plasma Frameworks - Commits
- R308:98aa41f388f4: [RunnerManager] Don't mess with ThreadWeaver thread count
It spent 30ms doing this on startup, now it's like 0.05ms
ThreadWeaver has essentially the same logic already. I just set the cap to be /2 of it to keep the old behavior (which I don't know the reason for)
Diff Detail
Diff Detail
- Repository
- R308 KRunner
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| src/runnermanager.cpp | ||
|---|---|---|
| 107 | Or should we keep this weird logic and substitute numProcs for idealThreadCount? | |
| src/runnermanager.cpp | ||
|---|---|---|
| 98–99 | Threadweaver defaults to At which point we basically have written: if( X > 2X ) which is never going to happen. Frankly I'd say let threadweaver do its own thing and not try meddling with it. | |
Comment Actions
It seems to me the only reason we have custom code to set the max count is because of that maxThreads config entry. An entry for which I can't see any UI backing, so it's borderline usless to begin with. The qMin then destroys any remaining use that entry may have head as we basically discard whatever was configured anyway unless it somewhat conforms to the hardcoded notion of how many threads make sense. So, I can't force a given thread count anyway.
I for one, would do away with the thread count twiddling and simply defer to whatever threadweaver says makes sense. Perhaps I am missing something though.