On Tue, 27 Jun 2017 22:55:54 +0200, Sönke Ludwig wrote:
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
array.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
lockConnection
currently iterates over the array to find a free connection, so the
efficiency argument is kind of moot, and this needs to be improved
anyway.)You could use a free list if you allocate a pointer along with each
array element.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
design ideas.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
redesign.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.
Sorry I meant the lock counts. In the hashmap
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.
The AA still allocates a block for each element. But you are right it should stabilize at some point.
-Steve