KDateTime value caching approach

[Frans Englich]

On Monday 21 August 2006 22:05, David Jarvie wrote:
> In kdepim, as Reinhold Kainhofer has pointed out, applications frequently
> have to store thousands of date/time values and to convert them on the fly
> to the viewing time zone, often multiple times. Time zone conversions
> (pre-KDateTime) already cause noticeable delays in some circumstances, and
> there is a need to make them more efficient in KDateTime. I think that
> KDateTime instances therefore need to cache not just their UTC equivalents
> as now, but also converted values in other time zones. I can think of 3
> approaches to take:
>
> - Cache all converted values in a QList, each element of which would
> contain a QDateTime and a KTimeZone pointer. To save space, the instance
> would only contain a pointer to the QList, the QList being created only
> when needed.

In that case, I think it's cleaner to have a global pointer. Wouldn't increase 
the object size, among other things.

Thread safety needs consideration. KDE needs a solution for Q_GLOBAL_STATIC, 
grr..

> - Cache just the last converted value. Then, if the instance was converted
> to another time zone, the previous conversion would be lost and would have
> to be recalculated if needed again.

> - Allow the application to set a configurable class-wide limit to the
> number of different time zones whose converted values will be cached. Then,
> if the application set the limit to 2 and the KDateTime was converted to
> Europe/Vienna and afterwards to Pacific/Kiritimati, the Europe/Vienna value
> would still be in cache for subsequent reuse. For this purpose, a QStack
> might be best, since it allows the latest conversion to easily be stored at
> the head of the list, thereby automatically discarding the oldest
> conversion if the limit is exceeded.
>
> There is obviously a trade-off of perfomance in return for memory usage,
> and the first option could in the worst case use up a very large amount of
> storage if values were converted to many different time zones. Since I'm
> not sure what range of requirements applications will have, I'm not sure
> about the best approach. Opinions would be welcomed, particularly if they
> are based on real-world requirements.

I don't think KDateTime should impose an optimization for a certain scenario. 
For some scenarios the conversion is needed only once, and in that case any 
caching only waste memory and cycles.

I think any caching mechanism or optimization in general, should be placed 
outside of KDateTime, somehow, such that no assumption is done on a 
particular scenario and that one can optimize for several different scenarios 
instead of hardcoding on one.

One possible approach could be to sub-class KDateTime("KCachedDateTime") and 
in that one heavily cache into a user-supplied pool(which can be a global one 
in kdelibs).

I would find shallow copying of KDateTime an advantage for my scenarios. 
Perhaps easy to do with QSharedData/QSharedDataPointer.


Cheers,

		Frans