Comment 8 for bug 1321775

I'm not able to reproduce the reported high CPU in indicator-datetime in build 53.

Setup:
I took a phablet freshly flashed to build 53, ran phablet-click-test-setup on the desktop followed by "click-buddy --dir . --provision" in the root directories of ubuntu-clock-app and ubuntu-calendar-app.
On the phablet I tweaked the autopilot directory to allow the ubuntu-calendar-app's tests to run (see lp:~nskaggs/ubuntu-calendar-app/fix-ap-env-setup).
In a separate phablet-shell, "powerd-cli display on bright"
Finally, I was ready to run the tests: "phablet-test-run -v ubuntu_clock_app", "phablet-test-run -v calendar_app", and "phablet-test-run -v ubuntu_clock_app".

Results:

1. During the first run of clock-app's autopilot tests, indicator-datetime's cpu stayed in the [0.0 .. 0.1%] range in htop and its cumulative time went from 0:00.75 to 0:01.91, a cumulative time growth of 1.16.

2. During the calendar-app autopilot tests, datetime's cpu use stayed in the [0.0 .. 0.1%] range in htop and its cumulative time went from 0:01.91 to 0:02.08,.

3. During the second run of clock-app's autopilot tests, datetime's cpu use stayed in the [0.0 .. 0.1%] range in htop and its cumulative time went from 0:02.08 to 0:03.18, an increase of 1.10, which is fairly consistent with the levels in the first test.

So nik90 or timo, if you're still able to reproduce this high CPU load in indicator-datetime is there a chance you could provide some information on either what steps I need to change to reproduce the behavior, or (say) a cachegrind profile of indicator-datetime taken during one of these high CPU sessions...