Re: Cost of constructing a communication path vs. sending a message

Mike Kristoffersen <[email protected]> Mon, 20 Sep 2010 15:20:26 -0500
Newsgroups gmane.comp.mozilla.devel.dom
Message-ID <[email protected]>
On Mon, 20 Sep 2010 14:11:08 -0500, Chris Jones wrote:

> On 09/17/2010 02:45 AM, Mike Kristoffersen wrote:
>> On Thu, 16 Sep 2010 22:41:11 -0700, Chris Jones wrote:
>>> On 09/16/2010 04:03 AM, Mike Kristoffersen wrote:

>>> Creating/destroying an actor is cheap, essentially |new
>>> FooActor()/delete actor|| and a hash table insert/delete on both
>>> sides.
>>>    Sending a message with IPC is much much more expensive than
>>> constructing/registering/unregistering/deleting an actor.
>>
>> I could be misunderstanding what you are saying, but what I'm hearing
>> is that you say it is cheaper to transmit information between the child
>> process and the parent process by doing a
>> "SendPGeolocationConstructor()" than sending a message like
>> "SendStart()" on an existing connection - if I didn't misunderstand
>> this, and we strive to use the cheapest solution, why do we have the
>> messages then, is it only to ensure communication between specific end
>> points?  (only talking about the async case here)
>>
>>
> No, you're misunderstanding ;).  I'm saying that the non-IPC parts of
> actor creation and destruction (new FooActor()/delete actor and hash
> table operations) are much much cheaper than sending a message with IPC.

I'm happy I didn't got it right the first time, I was very puzzled by the 
consequences of my initial understanding.  I guess the total cost is more 
important than the cost of each component.

>   The request-actor pattern can reduce extra IPC messages by having the
> the SendFooActorConstructor() message also mean "start request" and the
> Send__delete__() message also mean "stop request", instead of having
> extra (extraneous) StartRequest()/StopRequest() messages between
> SendCtor()/Send__delete__().

This time I think I understand what you are saying, at least this last 
bit makes sense to me this time (usually a good indicator).

Thank you for the help Chris.