Support durations for TTL

[WebFreak001]

The TTL settings for cache entries should support core.time : Duration, which makes the code more readable (5.seconds, 10.minutes) and also supports more accurate values than seconds.

You could also replace the time calls with MonoTime (from core.time) which can give you durations relative to two MonoTime values

[ikod]

Hello, Thanks for the report. I'd like to use durations for TTL, but they are not @safe. I'll check again. The same problem with other time functions. I didn't find any better solution than use time(null) and plain seconds. If there is safe solution I can change struct TTL implementation to use durations. Will be thankful for any hints here. пн, 14 янв. 2019 г., 1:40 Jan Jurzitza notifications@github.com:

…

The TTL settings for cache entries should support core.time : Duration, which makes the code more readable (5.seconds, 10.minutes) and also supports more accurate values than seconds. You could also replace the time calls with MonoTime (from core.time) which can give you durations relative to two MonoTime values — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNuSQ-YBhbHAb186xEdzJqiPsa6VGHrks5vC8PcgaJpZM4Z9cUG> .

[WebFreak001]

the Duration struct and all its functions are @safe (because it is just a long of nanoseconds which doesn't do anything else than providing some convenience methods), MonoTime.currTime is @trusted so I think it will all work fine

[ikod]

My fault.
Fix will take few days.
Thanks for hint and report!

[ikod]

Hello @WebFreak001 ,

It turns out that MonoTime.currTime is much slower than time() (see below), so current plan is: to use Duration in API calls to increase readability, but internally use only one second resolution for TTL and use fast time() call to trace expiration. It seems that 1 second resolution for ttl is enough.

import std.stdio;
import core.time;
import core.stdc.time;
import std.datetime.stopwatch;
import std.algorithm;

void tt() {
    time(null);
}
void mt() {
    MonoTime.currTime;
}

void main()
{
    auto r = benchmark!(tt, mt)(100000);
    r.each!writeln;
}

give output (https://run.dlang.io/is/jiMvs4)

732 μs and 9 hnsecs
455 ms, 533 μs, and 3 hnsecs

Any objections?

[WebFreak001]

MonoTime never runs backwards when changing the system clock or entering/leaving DST - time can run backwards in this regard and shouldn't be used for things like TTLs. If you want to use C APIs you should rather use clock_gettime(CLOCK_MONOTONIC, ...) (on linux) which is basically what MonoTime already wraps though.

You can use MonoTimeImpl!(ClockType.coarse) which will use a less exact monotime but still only run forwards (could be like milliseconds instead of hnsecs)

How often are the time functions called anyway? Would it even make any performance impact?

[ikod]

Hello, @WebFreak001

I pushed all changes to master.
TTL accept durations, also all expiration checks provided against MonoTime!(ClockType.coarse).

How often are the time functions called anyway? Would it even make any performance impact?

time functions called on each put iff any kind of ttl enabled, and on get if stored entry for given key have non-zero expiration time.

Yes, there is some performance impact, but we can't avoid it.

Code

import std.stdio;
import std.algorithm;
import std.datetime.stopwatch;

import cachetools.containers;
import cachetools;

void main(string[] args)
{
    CompressedList!string words;

    string fn = args[1];
    // fill list of words from file
    auto f = File(fn, "r");
    foreach(word; f.byLine.map!splitter.joiner) {
        words.insertBack(word.idup);
    }
    f.close();

    // run words through cache and count hits
    auto cache = new Cache2Q!(string, int);
    cache.size = 1024;
    cache.ttl(1.seconds);
    int hits;
    void fun() {
        foreach(w; words.range()) {
            auto v = cache.get(w);
            if ( !v.isNull  )
            {
                hits++;
                continue;
            }
            cache.put(w, 1);
        }
    }
    benchmark!fun(1).each!writeln;
}

produce next timings (ldc2, -release):
When ttl disabled:

408 ms, 923 μs, and 3 hnsecs

When ttl enabled:

444 ms, 135 μs, and 1 hnsec

If everything is ok, I'll close this issue.
Thanks!

[WebFreak001]

You could cache the value of MonoTime.currTime in the cache functions right? There is not a lot of delaying logic inbetween the calls and a difference of a few usecs wouldn't make it fatal I think, considering before seconds were the only supported accuracy.

Otherwise the changes seem to work good 👍

[ikod]

Ok, I'm closing this. Would like to fix remove safety restrictions.
Thanks for report this issue.