pcp
[Top] [All Lists]

Re: [RFC] dynamic container switching

To: nathans@xxxxxxxxxx
Subject: Re: [RFC] dynamic container switching
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Fri, 16 Oct 2015 20:43:55 -0400
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20151016223319.GH27211@xxxxxxxxxx>
References: <1313883527.54143616.1444783810135.JavaMail.zimbra@xxxxxxxxxx> <1539031958.54854689.1444886520071.JavaMail.zimbra@xxxxxxxxxx> <y0mr3kwku9s.fsf@xxxxxxxx> <1731194343.55415831.1444963601289.JavaMail.zimbra@xxxxxxxxxx> <20151016223319.GH27211@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

I wrote:

> By the way, how much processing time or space does this approach
> (pmStore then pmFetch) save, over doing it with current PMAPI [...]

Thinking of this again, I'm having trouble seeing how the pmstore
approach could improve performance.  On an amortized basis, assuming
multiple containers and that we need to query the same containers
repeatedly, the pmStore mode would have to look like

 pmNewContext
 pmStore (select-container X)
 pmFetch
 pmStore (select-container Y)
 pmFetch
 pmStore (select-container Z)
 pmFetch
 pmStore (select-container X)
 pmFetch
 pmStore (select-container Y)
 pmFetch
 pmStore (select-container Z)
 pmFetch
 [...]

whereas the classic way would be
 pmNewContext(X)
 pmNewContext(Y)
 pmNewContext(Z)
once, then:
 X->pmFetch()
 Y->pmFetch()
 Z->pmFetch()
 X->pmFetch()
 Y->pmFetch()
 Z->pmFetch()
 [...]

So classical separate contexts win in terms of round-trip
traffic, as soon as the *second re-query*.


- FChE

<Prev in Thread] Current Thread [Next in Thread>