[Bug translator/2115] support some function calls on maps

["hunt at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- 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.