-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: Friday, February 11, 2005 10:34 AM To: boost@lists.boost.org Subject: Re: [boost] [Signals] Named slot group usage?
On Feb 11, 2005, at 11:49 AM, Peter Dimov wrote:
Doug Gregor wrote:
On Feb 11, 2005, at 9:51 AM, Peter Dimov wrote:
Douglas Gregor wrote:
Background: Signals performance is sub-par, and much of the
can be traced back to support for named slot groups. I'm trying to determine the best way to proceed.
Are you sure that this is the case?
There may be other issues, but going from a std::list to a std::map (as needed to efficiently support connection of named slots) hurts iteration performance and increases executable code size. To counter the latter problem, I've done some type erasure that slows it down further and causes some of the extra heap allocations :(
You mean disconnection of named slots, right? List connection is O(1), map - O(log N). You get ordering for free with a map, sure, but this is a separate issue.
Both connection and disconnection of named slots are O(lg N), since we need to keep the whole list ordered when named slots are present. Connection/disconnection of unnamed slots is O(1) now.
Iterating through a map really is slow, though... loops in operator++ really hurt us. I've tried a few times to come up with some
Below: problem ultra-slick
formulation using a list for primary storage and a map indexing into the list... but I've always failed to deal with the iterator invalidation issues.
Anyway, I'm sure that few people would miss named slots.
That's what I'm trying to figure out; but I suspect that you're right.
Lets' drop them. :-)
You're not the only one to say that :)
Doug [Brian Braatz] What about allowing the internal type to be policy\traited?
i.e. I can use a vector instead of a map<> and is it possible to allow for meta-data while you're at it? Sincerely, Brian "wants the world on a silver platter" Braatz ;)
On Feb 11, 2005, at 3:21 PM, Brian Braatz wrote:
What about allowing the internal type to be policy\traited?
i.e. I can use a vector instead of a map<>
That gets really messy, really quick, and I only really know how to give sane semantics for list<> and map<>. I'm against policies except in very extreme circumstances.
and is it possible to allow for meta-data while you're at it?
Worry not, we'll find a way to get meta-data into slots :) Doug
participants (2)
-
Brian Braatz -
Doug Gregor