On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote: >>>> I actually think we should consider getting rid of shared_null and >>>> instead have d == nullptr as the null/default constructed state of >>>> the object. Yes, that means we need to check for d == nullptr in >>>> member functions, but I don’t think the overhead is a problem, as d >>>> will have to be loaded into a register in any case.
20.05.2019, 18:21, "Thiago Macieira" <[email protected]>: >>> It does introduce a compare-and-branch that wouldn't otherwise be >>> there, but the cost is minimal compared to what most API would be >>> doing, indeed. In plenty of cases, it's just calling the same-named method on the d-ptr. Result QThing::method(Type arg) { return Q_LIKELY(d) ? d->method(arg) : Result(); } On 20.05.19 17:27, Konstantin Tokarev wrote: >> We should wrap d == nullptr in Q_UNLIKELY() to make branch predictor >> assume non-null path by default. Olivier Goffart (20 May 2019 18:34) wrote: > I would not do that. Q_UNLIKELY does very little to the branch > predictor, it only tell the compiler to put that part of the branch in > a cold area (and also optimize for size instead of for speed) > Might not be a good idea considering that default constructed object > is actually quite likely. Is it ? I would hope that code relatively seldom calls methods on default-constructed objects or moved-from objects. Is the behaviour even well-defined ? Aside, of course, from assignment and destruction, the two places where I would indeed omit Q_UNLIKELY(). Eddy. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
