[Development] QDateTime is missing shared null optimization
Thiago Macieira
thiago.macieira at intel.com
Sat Aug 1 23:51:45 CEST 2015
On Saturday 01 August 2015 23:22:45 Robert Knight wrote:
> > 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.
That's a very good idea.
We'd need to check how complex the conversions would be, though.
QDateTime API accepts the offset from UTC in seconds, but all existing
timezones are multiples of a quarter hour. With a range from -12 to +13.5, we
need ceil(log((13.5 + 12) * 4) / log(2)) = 7 bits for the timezone. With the
one bit for the tag, we have 48 bits left for the msecs portion on 64-bit
platforms.
A 48-bit millisecond field spans 3257812 days. JD 3257812 is 4207-06-27.
Anyone want to try this?
Please note you cannot manipulate the this pointer in a member function, so
all the QDateTimePrivate member functions need to be made static first.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list