As you might have guessed, after a few conversations today (not very good ones, for the most part, I was tempted to give up the Internet.) I&#x27;ve been thinking about this code quite a bit in the last 12 hours.<p>I think you&#x27;re right that there might be an opportunities for improvement.  I admit that once the performance hit about 140 cycles per item, I mostly shrugged and called it a day.  I felt a lot more concerned about its safety across various architectures than bringing that cycle count down to the absolute minimum.  But I also did my benchmarking on x86_64, which has surprisingly strong memory guarantees by default, and so the difference here may be larger on other architectures.<p>Thanks for looking it over!  I definitely am interested and hope to grab some time to try benchmark some tweaks (and test for correctness) on a bunch of different architectures.<p>Unfortunately I don&#x27;t have all the state I&#x27;d need sitting at the top of my brain to revise this code at the moment, or even know whether your proposed changes are safe, since I find I can&#x27;t write atomics code safely unless I devote at least an afternoon to the process of analyzing the problem&#x27;s safety.<p>I remember there was a reason I chose using a shared item count instead of having the pointers be shared, I think mostly just to minimize the shared state to one thing, but it may not be the fastest choice.<p>If you want to give trying some changes a shot, I&#x27;d love to hear what you find!  Email is in my profile. :)