1238438SdteskeThings that still need to be done: -*- Text -*- 2238438Sdteske 3238438Sdteske o - Performance 4249746Sdteske 5238438Sdteske All performance could be tuned, but one area that could be looked 6238438Sdteske at especially is performance with flags, particularly 7238438Sdteske --detect-odr-violations and --compress-debug-sections. 8238438Sdteske 9238438Sdteske o - Threads 10238438Sdteske 11238438Sdteske Why is the usertime when we run with threads the same (or almost 12238438Sdteske the same) as when we run without? Is it because threads spend most 13238438Sdteske of their time waiting on the same resources? On each other? 14238438Sdteske Something else? 15238438Sdteske 16238438Sdteske o - ODR false positives 17238438Sdteske 18238438Sdteske ODR false positives can happen when we optimize, since code in .h 19238438Sdteske files may be optimized in different ways in different compilation 20238438Sdteske units. It's possible we could fix this for real by looking at the 21238438Sdteske full debug info and using DW_TAG_inlined_subroutine in a clever way 22238438Sdteske to correct for inlining. But that would be very expensive, I 23238438Sdteske think. The easier solution is to recommend people only do 24238438Sdteske ODR-detection with -g0. 25238438Sdteske 26238438Sdteske o - Better testing 27238438Sdteske