Julian Seward [:jseward] Reporter
	Description • 7 years ago

For small traversals, allocating and (in particular) deallocating thread-local
data is a significant overhead.  Profiling the first 300 restylings resulting
from [1] gives the following results, in instruction counts.  Profiling [2]
leads to the same conclusions.

geckoservo::glue::traverse_subtree total costs

#thr   #calls   #instr    of which |free| accounts for ..
p1      992x    3132 KI   (free = 219x   52KI)
p2     1022x    3425 KI   (free = 225x  300KI)
p4     1007x    3692 KI   (free = 222x  538KI)
p8      992x    3979 KI   (free = 219x  763KI)
p16     962x    4485 KI   (free = 213x 1183KI)
p32     992x    5744 KI   (free = 219x 2167KI)

Even with 2 threads, we're using 300 K insns in free(), viz, 8.8% of total.
With 4 threads that's 14.6%.  In the limit it's clear the TLS free costs
will dominate all other costs.  It's particularly bad because freeing, hence
poisoning the TLS, is going to cause a bunch of MESI protocol misses since
(by definition) it's been pulled into potentially all other core's private
caches.

It would be good to get rid the TLS allocation/freeing for every traversal,
or at least make it a lot smaller, so the scaling effects aren't something
we need to worry about for a few years.

[1] https://github.com/heycam/style-perf-tests/blob/master/perf-reftest/tiny-traversal-singleton.html

[2] http://speedometer2.benj.me/InteractiveRunner.html, per bug 1371496

	Bobby Holley (:bholley)
	Comment 1 • 7 years ago

This is probably less important now that we have the adaptive traversal (bug 1393632). Still could be worth doing, but probably doesn't block shipping.

	Firefox Bug Husbandry Bot
	Comment 2 • 7 years ago

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals