Simplify param method: Return Early, Use a Map and Assert.
AbandonedPublic

Authored by tcanabrava on Dec 20 2019, 7:11 PM.

Details

Reviewers
ervin
dfaure
Test Plan

Recompiled and runned the unittests

Diff Detail

Repository
R237 KConfig
Branch
simplifyParam
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 20093
Build 20111: arc lint + arc unit
tcanabrava created this revision.Dec 20 2019, 7:11 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptDec 20 2019, 7:11 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
tcanabrava requested review of this revision.Dec 20 2019, 7:11 PM
apol added a subscriber: apol.Dec 23 2019, 1:53 AM

I'd make the types static const, or at least const.
Also are you sure that here std::map is better than QHash?

static will add a Mutex in the generated assembly (as static variables in c++ are now thread safe) and I'm not sure this is a good thing for const - reading variables. I'll try another approach so we only initialize it once.

apol added a comment.Dec 23 2019, 2:41 PM

Why are you concerned about thread safety in the kconfig compiler? :/

I’m not. I’m concerned that the introduction of thread safety by adding a
static member will make the compiler slower.

ervin added a subscriber: ervin.Dec 23 2019, 4:37 PM

static will add a Mutex in the generated assembly (as static variables in c++ are now thread safe) and I'm not sure this is a good thing for const - reading variables. I'll try another approach so we only initialize it once.

Thread safe doesn't necessarily mean there will be a mutex... Depends if it's a literal type or not for a start, also it's generally implemented using the double locking pattern with atomics so if there's a mutex it's likely to be involved only one time on first call of the function.

ervin added inline comments.Dec 23 2019, 4:40 PM
src/kconfig_compiler/kconfig_compiler.cpp
1024

std::map looks like a bad idea here, either use QHash (preferred in massively based Qt code) or std::unordered_map.

Also for both temporaries you pay the price of their allocation and deallocation at each call. Even a mutex used at each call would do better. ;-)

This revision now requires changes to proceed.Dec 23 2019, 5:07 PM
dfaure requested changes to this revision.Dec 24 2019, 8:40 AM
dfaure added a subscriber: dfaure.
dfaure added inline comments.
src/kconfig_compiler/kconfig_compiler.cpp
1020

This linear search doesn't look like an optimization to me. It would be better to incorporate this into the map, so that a single search is performed, rather than two.

1024

I'm not 100% sure about std::map vs QHash given the number of elements, this would need benchmarking.

But I agree 100% that compiler-generated thread safety around a static is NOTHING compared to amount of nodes allocated to fill in a map or hash.

@tcanabrava Please have a look at https://gist.github.com/jboner/2841832
Locking an available mutex is 4 times faster than even fetching data from main memory (i.e. data which isn't yet in a CPU cache). This is many orders of magnitude faster than creating a filling a map or a hash full of QStrings. On top of that, compilers don't even generate a full-blown mutex for threadsafe statics, they generate a three-state atomic (a bit like Q_GLOBAL_STATIC does) (3 because not created, being created, already created).

The most performant solution is to turn the input string into a QByteArray and then perform a binary search in a C array of const char* (no allocations, even the very first time).
The most readable (but still good, unlike the current code in git) solution is a static map.

David,

Thanks for the detailed explanation, I'm currently reworking most of the
patches here. About the optimizations - I know the linear search is a bad
optimization, but it adds legibility, that's what I tried to do.
I tried to emulate the python if value in vector that is really easy to
read, compared to the current code.

tcanabrava abandoned this revision.Jan 29 2020, 5:27 PM