Re: How cheap/efficient is it to have lots of protocols/instances?

On 8/28/09 1:16 PM, Jason Duell wrote:
> Thinking about the necko protocol layer, I'm realizing I've got a
> choice between two general models:
> 
> 1) Have a single Necko protocol, and one instance per content process,
> over which I multiplex all the channels that are opened.
> 
> 2) Create a "NeckoChannel" sub-protocol of the Necko protocol, and
> create an instance of it per-channel.

Use sub-protocols. Sub-protocols need to be cheap, and make your code a lot
safer in that the IPDL mechanism itself can do resource tracking and
parameter validation.

> How expensive, roughly speaking, is IPC traffic?  Do we have data
> structures in place what will keep things efficient with large N
> (well, medium N) numbers of protocol instances?  I assume we're

I can't imagine that there are going to be more than, say, 2000 channels at
a time, and that's not enough to think about worrying about in terms of
memory usage or tracking overhead.

> ultimately multiplexing protocols over a single pair of pipes per
> process, and not doing something like popping open new kernel data
> structures at protocol instance creation.   Any other considerations

Correct.

> for choosing model #1 or #2?  One thing I'm worried about is losing
> the ability to make optimizations like having a LoadGroup cancel
> result in 1 IPC msg, rather than 1 per channel involved.  There might
> be no way to avoid that if IPDL destructors have to be called
> separately for each channel involved.  But if it's cheap enough (or
> IPDL is smart enough to bunch a batch of msgs into a single pipe read/
> write), this might not be a factor.

Currently there is no batching, and you do have to send an independent
message for each protocol destructor. It's possible that we could invent
more efficient ways of destroying a bunch of subprotocols at once. I would
only want to do that if it showed up in profiles, though: I don't think in
general that there are enough network objects that it will ever be noticable.

--BDS