| 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> |
|---|---|---|
| ||
| Previous by Date: | qa/709 failing pmcollectl python, Ken McDonell |
|---|---|
| Next by Date: | Re: [question] PCP UI FrontEnd, Ken McDonell |
| Previous by Thread: | Re: [issue] pmwebd graphite api performance issue, Frank Ch. Eigler |
| Next by Thread: | RE: [issue] pmwebd graphite api performance issue, Aurelien Gonnay |
| Indexes: | [Date] [Thread] [Top] [All Lists] |