[Development] QDateTime is missing shared null optimization

[Robert Knight]

> What I mean is that you'll incur a heap allocation when doing
> ...
> I don't think there is and there has never been any inline method in QDateTime
> that dereferences the d pointer, so using a nullptr to indicate shared null is
> acceptable.

Hmm, perhaps QDT could avoid a heap allocation entirely in common
cases on 64-bit systems? eg. When using a standard timezone (no custom
offset) and the date/time can be represented as a positive offset from
the UNIX epoch less than some max value.  Something like 42 bits for
ms since 1970, 5 bits for the timezone, 1 tag bit to indicate not a
d-ptr.  Its quite possible I missed some obvious flaw, but just a
thought.

On 31 July 2015 at 18:08, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Friday 31 July 2015 17:20:02 Milian Wolff wrote:
>> Most other classes in Qt are cheap to generate in an empty/invalid state,
>> not so for QDateTime. Is there a  reason for that, or is it just an
>> oversight?
>
> Oversight.
>
>> If so, I'd like to amend that. Would it be preferred to
>> introduce a shared null like QTypedArrayData::sharedNull, or should I
>> rather use a nullptr to indicate the invalid state, like in QImage? Or am I
>> missing something and these tricks are not applicable to QDateTime?
>
> I don't think there is and there has never been any inline method in QDateTime
> that dereferences the d pointer, so using a nullptr to indicate shared null is
> acceptable.
>
> I also don't think you can have a full, static shared null because
> QDateTimePrivate is not POD, due to its QTimeZone member. So a real shared
> null would be a Q_GLOBAL_STATIC, if you chose to go that route.
>
> Another piece of information is that I removed all sharing in Qt 5.5 because
> it was badly implemented before. QDateTime does a lot of lazy evaluation,
> which is incompatible with implicit sharing. You have to choose one or the
> other.
>
>> Grepping for QSharedDataPointer, I find many more classes that do not
>> leverage a shared null state. Should  we try to implement some helper
>> functions/macros there which can be leveraged by every user of this class
>> to implement a shared null state?
>
> Some of them may not do it because of the lazy evaluations I mentioned.
>
> Another is that QSDP/QESDP don't do a clone-from-null very well. I think there
> are a couple of specialisations of QSDP<T>::clone that implement this
> functionality, which you can grep for. Check with Marc' and see if his new,
> internal shared pointer class could take this optimisation.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development