pcp
[Top] [All Lists]

Re: [issue] pmwebd graphite api performance issue

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: [issue] pmwebd graphite api performance issue
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 28 Jul 2015 14:35:06 +1000
Cc: pcp@xxxxxxxxxxx, aurelien.gonnay@xxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20150728002629.GD6728@xxxxxxxxxx>
References: <a00f452763fd43f98eb5123d3ec0c3cf@xxxxxxxxxxxxxxxxxxxxxxxxx> <55B69826.7030103@xxxxxxxxxxxxxxxx> <y0mpp3d1bqq.fsf@xxxxxxxx> <55B6B597.1070909@xxxxxxxxxxxxxxxx> <20150728002629.GD6728@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
G'day Frank.

On 28/07/15 10:26, Frank Ch. Eigler wrote:
..
That could work too, though doing it naively could involve O(#metrics**2)
iteration, which could itself be heavy. ...

The old computational complexity meets reality trap ... not all operations have the same cost.

I'll wager that for any von Neumann machine with real values of #metrics (and #instances), an O(#metrics**2) times for loop with simple test (p->indom == indom_of_interest && p->done == 0) will beat the pants off any O(#metrics) times loop with pmGetInDomArchive() + free()

... Doing it the cache way in pmwebd
turned out to be easy:

OK, sounds good.

Cheers, Ken.

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