Re: smrproxy v2

On 12/9/24 13:34, jseigh wrote:

On 11/27/24 10:29, jseigh wrote:

I'm going to drop working on the whole proxy interface thing.  The
application can decide if it wants to hardcode a dependency on a
particular 3rd party libarary implementation or abstract it out
to a more portable api.
>

 I figured out where the smr vs smrlite overhead is likely coming from.
 1) thread_local load about .3 nsecs, 2 for lock/unlock so .6 nsecs.
2) overhead from lazy initialization, about .6 nsecs.
 smrlite most of the time doesn't show any measurable overhead,
0 nsecs.

Fixed the whole thread_local issue.  Just don't use it.  I
went back to the api I was using in C and leave it up to
the app to keep track of thread local objects. Fixes the
problem of multiple proxies needing multiple per thread
objects.  This is a language issue, not an api issue.

 Theoretically, you could do do lazy initialization with zero
runtime overhead, but for most c++ apps, 1 millisecond is
considered fast, so I don't think there would be much interest
in it.

And apparantly I am right. :)
Joe Seigh