Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Mon, 30 Jun 2025 10:02:27 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock In-Reply-To: References: List-Id: X-GitHub-Author-Login: vlsi X-GitHub-Comment-Id: 3018548514 X-GitHub-Comment-Type: issue_comment X-GitHub-Edited-At: 2025-06-30T10:03:03Z X-GitHub-Issue: 3693 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693#issuecomment-3018548514 Content-Type: text/plain; charset=utf-8 > At first impression I'm not really sure I sympatise with a user expecting a very specific behaviour from a concurrent, uncoordinated call to getWarnings ? The thing is pgjdbc is wildly used in many applications, so we want to avoid breakages even for the clients who are not doing the best possible thing. > Attaching a new flamegraph zip file, hopefully this works better. This works much better, thank you. Do you think you could share the source data for it? (I mean stacks.txt file or jfr or whatever was the raw data for the flamegraph) > Slightly off-topic, but I'd also love it if the cache implementation could be pluggable Sure Caffeine is an option, and we "discuss" it here: https://github.com/pgjdbc/pgjdbc/issues/345#issuecomment-320901092 The default artifact will likely shadow Caffeine to avoid clashes with pgjdbc users' Caffeine though. --- An interesting experiment could be to replace `ResourceLock` with a dummy class that does nothing, and then compare the thoughput, cpu utilization and the latency numbers. Sure we can't shave all the synchronization, however, it could probably give rough estimates on the improvements possible.