Oibaf
14th July 2017, 21:54
Hi all,
I am using QDateTime extensively in a series of procedures that need to run as fast as possible, under 250 milliseconds in total, therefore I really want to avoid heap allocations as much as possible.
However, I just realized that QDateTime allocates its internals on the heap, sharing them with other QDateTime objects until they are modified. This might be fine when the datetime object gets just passed around, but it seems overkill when lots of operations have to be done on it, resulting in multiple temporary copies and therefore multiple temporary heap allocations.
To be totally honest I've not done any extensive profiling to determine whether this is in reality an issue, but just in case I find that the heap allocations really waste too much time, what obstacles do you think there would be in building a QDateTime-alike class that embedded directly in itself a pair of QDate and QTime objects, providing the same interface as QDateTime's?
Has this ever been done before?
I am using QDateTime extensively in a series of procedures that need to run as fast as possible, under 250 milliseconds in total, therefore I really want to avoid heap allocations as much as possible.
However, I just realized that QDateTime allocates its internals on the heap, sharing them with other QDateTime objects until they are modified. This might be fine when the datetime object gets just passed around, but it seems overkill when lots of operations have to be done on it, resulting in multiple temporary copies and therefore multiple temporary heap allocations.
To be totally honest I've not done any extensive profiling to determine whether this is in reality an issue, but just in case I find that the heap allocations really waste too much time, what obstacles do you think there would be in building a QDateTime-alike class that embedded directly in itself a pair of QDate and QTime objects, providing the same interface as QDateTime's?
Has this ever been done before?