Thanks for reporting. While Okteta ideally could also help with this problem by only creating the KDirModel if needed, this would only work-around the real problem, which seems KSystemTimeZoneBackend doing something that results in reading /etc/localtime and the zoneinfo file again and again, instead of caching the timezone or whatever could be done here. So pushing this bug over there.

Perhaps KDirModel/KFileItemDelegate could also be improved, as from the backtrace given KLocale::formatDateTime is only called on a new icon to be set due to the mimetype of a file being resolved.

David at #281360 is looking at optimizing KSystemTimeZone, so one approach is on the way.

Applied fix from bug #281360 but okteta still "hangs"  doing bunch of:


[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
[pid  4515] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0

Honestly I think it's as simple as having to go through the very slow path of KSystemTimeZoneBackend::offsetAtZoneTime(). By "very slow path" I mean KDateTime trying to display a formatted time in a different time zone than the time zone the program is running in.

POSIX does not give a good way to translate times between different time zones, so their documentation recommends changing the TZ environment variable and re-running the tzset() function. According to the tzzset documentation, it will typically read the /etc/localtime file if the TZ environment variable is set to ":" or if TZ is left unset.

Since KSystemTimeZone has to reset TZ to its original value (set or unset) after determining the offset to the requested time zone, it is possible that all the /etc/localtime stat() calls are due to unsetting TZ and then running tzset().

It might be possible to confirm this by running okteta from a shell:

$ export TZ=:Europe/Warsaw
$ okteta

(with TZ set to a colon (:) followed by whatever your time zone actually is).

If it turns out this is the problem the solution is either to not do the work (i.e. don't convert timezones just to show a date, which means look at the Locale settings to ensure your normal date format doesn't show any timezone or UTC offset info), or to do less work (perhaps this function doesn't need to be called at all for displaying a date, but I'm not able to follow the backtrace fully).

You may also want to look at your system timezone setting to make sure it matches the time zone setting you have set in your KDE Locale settings.

I'm using Europe/Warsaw timezone, "Country" is set to "Poland", "Languages" -> "American English", date format is "WEEKDAY DD MONTH YYYY" for long date and "DD/MM/YYYY" for short date. I'm not installing/using any l10n kde packages. Timezone setting in kde is "Europe/Warsaw (CEST)" which is consistent with what I have in /etc/localtime.

TZ=:Europe/Warsaw makes okteta no longer read /etc/localtime but it still takes like 30s to get GUI responsible (so it's A LOT faster than without such TZ setting but seems there is additional issue hidding here).

KSystemTimeZones has been changed so that it now returns KTzfileTimeZone instances, not KSystemTimeZone instances (see comments in bug 281360 for details). So comment #5 is not relevant - tzset() is no longer used by KDE classes. (Note that /etc/localtime isn't being opened multiple times any longer - it's only being stat()'ed - so it can't be tzset() which is responsible.)

If the /etc/localtime accesses are from KDateTime, I suspect that the culprit may be QDateTime::currentDateTime(), or even the libc time() function, which are called by KDateTime::currentDateTime(), currentLocalDateTime() and currentUtcDateTime(). Alternatively, the accesses may not be from KDateTime at all (I haven't looked at the Okteta code, so I don't know).

One change which could make a significant improvement would be to minimise the number of times the current date/time is fetched, by whatever method. If it is needed more than once inside a function, or if it is used in multiple functions which are called from one another, it's a good idea to fetch it only once and save its value in a variable, passing it to other functions where possible.

When I compile kdelibs in debug mode, simply starting okteta results in hundreds of lines "-> No cache" and "-> Using cache". I guess either the cache isn't effective (it should only show the "No cache" once), or okteta is somehow querying different data all the time, so that the cached values are not of any use.

The "No cache" and "Using cache" messages indicate whether the cached value in a time zone instance is being used or not. When a date/time value is converted to/from UTC, the cached time zone transition information is used (i.e. "Using cache") if the value is in the same year and summer/winter time state as the last value converted. This saves significant processing. If they are in different years or different summer/winter-time state, the time zone offset must be recalculated (i.e. "No cache").

Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!

Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!

Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!

As far as I can see, since the time this bug was reported okteta has had no direct calls to KDateTime or KTimeZone, and the dependency on these classes was via KDirModel in kio. On the assumption that frameworks/kio no longer links to kdelibs4support, okteta will no longer use KDateTime directly or indirectly, so this bug will not occur any more.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!