Re: SystemDependentDataBuffer bits ...

Hi everyone,

the following is just some guess work, as my build will take much longer to verify.

I had a look at the code and the timer fires every second. That would mean one
call to Start() for every second, which could trigger the message via timeout,
which is slightly less then:

> <mmeeks> vmiklos: ~150k of those while typing ~3 lines of random text in
> writer =)

The only thing left is thousands (missed the "k" in 150 at first glance) of
calls to startUsage and endUsage, always resulting in an empty list, which
starts and stops the timer all over again.

>       * should we not disable the SystemDependentDataBuffer ie.
>         remove:
>
>                 if(maEntries.empty() && maTimer)
>                     maTimer->Stop();

That wouldn't help, as the main problem is all the Start() calls in startUsage.
These are "expensive" (and Start() actually should be named Restart()), which
means the Scheduler eventually has to calculate the next timeout. Probably not
the best API.

OTOH Stop() just sets a bool and the Scheduler eventually will do some cleanup
of the stopped task next time it is run. We just "risk" to wake up too early; once.

But I suspect the cache is currently broken in some way. Nothing is really
cached, as it looks like every entry is immediately evicted again.

I've pushed an untested patch to Gerrit as https://gerrit.libreoffice.org/71376.
I'm quite sure, this doesn't change anything, unless some code directly invokes
the task not even waiting for the timeout.

HTH

Jan-Marek