Posted Tue, 27 Jun 2017 22:55:54 +0200 in reply to Steven Schveighoffer
Am 27.06.2017 um 18:47 schrieb Steven Schveighoffer:
On 6/26/17 2:40 PM, Sönke Ludwig wrote:
In general, nothing speaks against adding a way to discard
connections. It's mostly just that all previous use cases involved
high level connections that had to carry a connection reestablishment
logic anyway, and removing an arbitrary connection is not efficient
for many concurrent connections, because right now they are kept in an
Well, you return them by value anyway. So swapping the removed
connection with the last element should work and be an O(1) operation.
You'll still have to locate the element in O(n).
(Having said that, I've just looked at the code and
currently iterates over the array to find a free connection, so the
efficiency argument is kind of moot, and this needs to be improved
You could use a free list if you allocate a pointer along with each
There are also other ways to optimize. You are actually storing a hash
for the semaphores, which is allocating a bunch of little blocks anyway.
I think the whole structure can be made much faster with some better
Very true. The connection pool was basically implemented without
performance in mind so far, originally just to have something working,
and was then never being looked at again, except for a PR where the
semaphore was added. I've also overlooked it during the big vibe-core
What do you mean by semaphores, though? There is only one of those
per pool and there shouldn't be any small internal allocations going on.
But the AA that is currently used for the reference counts is another
obvious target, although that fortunately shouldn't be a big issue once
the connection count stabilizes, thanks to the open addressing of the
improved AAs. Still not necessary.