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

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.

The latter would save me the fuss of keeping some track of which
content channels map to which chrome channels.  But it also means that
we'd be frequently creating/destroying protocol instances.  This could
cause some extra IPC overhead (though possibly not much, if I can
delay calling NeckoChannelConstructor() until AsyncOpen time, and thus
piggyback channel construction on the AsyncOpen IPC that was going to
happen anyway).

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
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
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.