From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32474 invoked by alias); 16 Jan 2006 09:20:43 -0000 Received: (qmail 32454 invoked by uid 48); 16 Jan 2006 09:20:37 -0000 Date: Mon, 16 Jan 2006 09:20:00 -0000 Message-ID: <20060116092037.32453.qmail@sourceware.org> From: "hunt at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20060106181230.2115.hunt@redhat.com> References: <20060106181230.2115.hunt@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/2115] support some function calls on maps X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00165.txt.bz2 ------- Additional Comments From hunt at redhat dot com 2006-01-16 09:20 ------- (In reply to comment #4) > Re "printa", we've been over this several times, and the existing > sorted-foreach/print pair was not worse than the proposed sort/print sequence. I only agreed that the script complexity was not too much worse. Because you can extend the foreach to do anything you want: foreach ([a,b,c+,d] in foo limit 10 mormalize 1024) { printf("foo[%d,%d,%d,%d]: count:%d sum:%d avg:%d min:%d max:%d\n", a, b, c, d, @count(foo[a,b,c,d]), @sum(foo[a,b,c,d]), @avg(foo[a,b,c,d]), @min(foo[a,b,c,d]), @max(foo[a,b,c,d])) print(@hist_log(foo[a,b,c,d])) } - compared to something like - sortn(foo, KEY3, 10) normalize(foo, 1024) printa(foo, 10, "foo[%1,%2,%3,%4]: count:%C sum:%S avg:%A min:%m max:%M\n%H) When comparing lines of code generated, which increases compile time and module size, there is no comparison. The second approach is just a a few calls to the runtime. When comparing executing time, the best case showed the foreach taking 50% more time and that was for plain maps. Stats are worse. Worse case is much, much worse. The reason should be obvious if you look at the code generated. Foreach iterates through the map nodes getting keys. Then it uses those keys over and over again to look up the node it already had to get stats pointer to get count, then sum, etc. Worse case is keys are 5 strings so each of those is copied twice, hashed, etc. Of course execution time is really only a concern when using timers because we are holding a lock. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2115 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.