OK, I found the source of the performance hit. In the POOL-411 changes, we had inadvertently forced every register to acquire a write lock from the keylock. I think I also finally definitively fixed the root issue there. The tricky bit about the numInterested tracking is that the counters are attached to the ObjectDeques, which can be replaced. If this happens while waiting for a write lock in either register or deregister, the code can end up updating the counter on a pool that has been replaced. I added checks to trap deregistration of a null pool (should never happen) and followed Sebb's suggestion to add a check for numInterested going negative. The accounting setup is very efficient, but tricky to maintain. For 3.0, we might consider moving numInterested tracking to a hashmap. For 2.x, I think the setup is fixed now and performance is the same as earlier versions. Soak tests look good.
One last thing I would like to do before we cut 2.12.0: We are going to be making incompatible changes in 3.0 and I don't think we need to telegraph all of the API changes via deprecations in 2.x - most notably the recent method name changes of the form s/Time/Duration. I understand the rationale for these changes, but they make the 2.x code very messy with double deprecations - first from the "millis" methods and then from "Time" to "Duration." I think it would be better to keep the existing deprecations for the "millis" methods, but drop the new "Duration" ones and remove deprecations for the ones they replace. I can see the argument that it is better to tell users now, but that takes away flexibility in 3.0 and makes the API look very confusing with so many methods that do the same thing. Any objections ? Phil On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz <phil.ste...@gmail.com> wrote: > I have run my first round of soak and performance tests on what is now in > the 2.x branch. Good news is the code looks stable. Not so good news is > it appears that GKOP performance has taken a material hit vs 2.11 and > earlier versions. I need to confirm this via more targeted tests and if it > turns out not to be real, figure out what is causing it. Hopefully I will > get to this done in the next few days. > > Phil >
