📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/178ebd27e40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14f3cf40140000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/135fa888140000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/138f034be40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14f3cf40140000

Use TLS to stash the thread id on linux. by dtapuska@chromium.org
https://chromium.googlesource.com/chromium/src/+/5efc4727bcd983d81b3ae676b184bddcaac3095b
thread_raster_cpu_time_per_frame: 0.009404 → 0.006953 (-0.002451)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/138f034be40000

Use TLS to stash the thread id on linux. by dtapuska@chromium.org
https://chromium.googlesource.com/chromium/src/+/5efc4727bcd983d81b3ae676b184bddcaac3095b
thread_total_all_cpu_time_per_frame: 2.976 → 2.877 (-0.09954)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/178ebd27e40000

Use TLS to stash the thread id on linux. by dtapuska@chromium.org
https://chromium.googlesource.com/chromium/src/+/5efc4727bcd983d81b3ae676b184bddcaac3095b
thread_raster_cpu_time_per_frame: 0.08845 → 0.08362 (-0.004822)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

dtapuska@chromium.org, it's pretty clear you caused several improvements. Great work!

See the above links for the specific benchmarks.



I don't see any indications that this change was responsible for the paint-time drop we saw in UKM data on gmail though. I'm afraid it looks like we don't have perf tests that cover the improvement we saw in the wild. I'm going to close this as we will have to use another approach.

pdr@ That is great there were concrete metrics improved.
Can you tell me where the call sites of these calls were? (blink should already be caching all this stuff in TLS, so it really possibly means that the gpu or compositor was making swi calls)

I wonder if we should have a similar change for getpid() which glibc stopped caching.

I am not sure where the calls are from; I just ran these pinpoint jobs looking for the cause of another progression and they ended up showing your change as being the cause.

Are these benchmarks calculated from tracing? The change definitely did make tracing more lightweight avoiding at least two swis for every logged trace macro.

I think most of our benchmarks are tracing-based. If this made tracing more lightweight, that's a plausible explanation for this progression. Alas :/