TYPO3 Core

I guess this is related to the modified TimeTracker (TT) object which is not initialized anymore when logged into the backend.

Yes, it's related to the timetrack object, which is a null object if no BE user is logged in.

We could easily fix this by making getMilliseconds() in t3lib_timeTrack a static method.

I think it would be okay to only enable the timetracker,
if you're logged in to the backend and have admin-rights.

But then this should be clearly stated in the source somehow,
or nothing should get displayed at all.

Generally this throws up the idea of a debug-mode which
gets enabled by setting a GET variable, when logged in to
the backend; maybe a secret phrase. (Just an idea.)

The parsetime is only added as a comment after the </html> if $TYPO3_CONF_VARS['FE']['debug'] = '1'; is set. So we don't need another special GET var or something.

I propose to reanimate getMilliseconds() somehow to make this work again without BE login.

Attached a simple patch which ads implementation of getMilliseconds() to timetracknull, but this solution is not very nice.

If getMilliseconds() in t3lib_timetrack is made static it would have these disadvantages:
- Breaks backwards compatibility
- another class need to be loaded in FE

Maybe it would be better to add a new static class for time handling and calculation and deprecate those methods in the timetrack classes. t3lib_div has some more related methods: convertmicrotime(), milliseconds()

Just discovered the issue w/version 4.3.3 (upgraded from 4.2.12). The patch did resolve it for me and now. But please note also the disadvantages...

This is all about measuring performance in FE.
I think it's pretty pointless to enable this on ALL installs worldwide.
Log into the BE and you're done.

We disabled TT for a good reason and up to now I don't see any to re-enable it :)
/discuss

Here's a good reason:

When you are logged into the TYPO3 backend, you'll getting much higher parsing times rendering a frontend site, compared to the same site, when you are not logged in. (no admin-panel, etc. active...)

I tried that with different benchmark tools.

Is there are reason why? Can someone reproduce that?

regards

This issue occures also in 6.2.5. No matter if you are logged in or not - always 0ms.