New issue
Advanced search Search tips

Issue 843364 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

1.7% of non-idle UI thread runtime is spent in icu_61::TimeZone::detectHostTimeZone()

Project Member Reported by wittman@chromium.org, May 15 2018

Issue description

The execution profile for this thread in 68.0.3428.0 canary on 64-bit Windows shows that this function is taking 1.7% of non-idle runtime:
https://uma.googleplex.com/p/chrome/callstacks?sid=6bff3c4f90a80e680923370c3f48c986

Apparently this is calling NtQuerySystemInformation under the covers which is known to be a very expensive function -- measured @ 4ms/call.

The runtime is not uniformly distributed, however. For clients observed executing this function here's the percent of their time spent executing it at every 5th percentile:
0,0,0,0,0,0,0,0,0,0,1,1,1,2,5,12,30,46,63,75,100

So the top 20% of clients observed executing in this function are spending 30+% of their execution time there.
 
Bruce, do you know of someone who could take this?
Cc: js...@chromium.org
I think there are two possible problems here:

1) What is causing TimeZoneMonitor::NotifyClients to be called frequently enough for its CPU consumption to show up? If there is a bug around this then fixing that bug will have the biggest impact.
2) Why does the ICU function TimeZone::detectHostTimeZone() call tzset (through uprv_tzset) every time? It should only be necessary to call it once, I believe.

Fixing either one or both of these issues would save CPU time and power. I can provide Windows expertise. Adding a time zone domain expert.

Comment 3 by js...@chromium.org, Jun 20 2018

As for #2,   it may be better not to call _tzset() (uprv_tzset) at all (even for the first time) on Windows unless we want to respect TZ environment variable on Windows. 
(  https://msdn.microsoft.com/en-us/library/90s5c885.aspx ).  OTOH, removing that may not cut down the cost much ( _tzset() does not appear to be expensive). 

I think we have to find out why  TimeZoneMonitor::NotifyClients is called so frequently. That's supposed to be called only ON a timezone change event, which should be extremely rare. 

It looks like TimeZoneMonitor::NotifyClients is being called when receiving the WM_TIMECHANGE message[1], which MSDN says is sent whenever there is a change in the system time. Bruce, do you have an idea why some clients would be receiving this message so often?

1. https://cs.chromium.org/chromium/src/services/device/time_zone_monitor/time_zone_monitor_win.cc?rcl=105c0431482238b421f530a437744e1d28c30968&l=29-35

Sign in to add a comment