RE: [boost] [Signals] Named slot group usage?

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-02-11 15:21:57

Below:

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Doug Gregor
> Sent: Friday, February 11, 2005 10:34 AM
> To: boost_at_[hidden]
> 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
problem
> >>>> 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
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 
;)