Store events in thread local buffer in simple format, convert to proto when flushing

[dsharlet]

Instead of encoding a protobuf directly into the thread local buffer, we could just record a simple struct of events, and generate the protobuf when flushing to the file.

This would reduce overhead in the tracing functions, but would cause flushes to be slower instead. There are pros and cons to this.

[dsharlet]

I'm not sure this really makes sense. Here's a profile of on a trivial loop of mutex lock, unlock on a single thread:

  56.53%  benchmark  [vdso]                [.] __vdso_clock_gettime                                              
  19.92%  benchmark  libc.so.6             [.] __memmove_avx_unaligned_erms                                      
   5.22%  benchmark  pthread_trace.so      [.] (anonymous namespace)::thread_state::write_end                    
   4.54%  benchmark  libstdc++.so.6.0.30   [.] std::chrono::_V2::system_clock::now                               
   2.80%  benchmark  pthread_trace.so      [.] (anonymous namespace)::thread_state::write_begin_with_delta<2ul, (
   2.17%  benchmark  pthread_trace.so      [.] (anonymous namespace)::thread_state::write_begin<(anonymous namesp
   1.96%  benchmark  ld-linux-x86-64.so.2  [.] __tls_get_addr                                                    
   1.41%  benchmark  libc.so.6             [.] pthread_mutex_lock@@GLIBC_2.2.5                                   
   0.69%  benchmark  libc.so.6             [.] clock_gettime@@GLIBC_2.17                                         
   0.67%  benchmark  libc.so.6             [.] pthread_mutex_unlock@@GLIBC_2.2.5                                 
   0.67%  benchmark  pthread_trace.so      [.] pthread_mutex_unlock                                              
   0.64%  benchmark  libstdc++.so.6.0.30   [.] 0x000000000009eb10                                                
   0.58%  benchmark  pthread_trace.so      [.] pthread_mutex_lock                                                

• I don't think there's much room to improve reading the clock
• The memcpy is mostly copying from the thread local buffer to the global circular buffer

So it seems like at most a ~30% improvement is on the table. That's probably not worth a lot of added complexity...