1

In various other caliper posts, it would seem that Caliper was approaching a 1.0 release sometime in October (i.e,. in August the answers were along the line "wait two months"), but there hasn't been any activity in the git repo since June 18th. Any update?

BeeOnRope
  • 60,350
  • 16
  • 207
  • 386

2 Answers2

1

I hope to have it out very early next year.

gk5885
  • 3,742
  • 21
  • 16
  • Sweet. Does it have any way to specify the column ordering? – BeeOnRope Dec 12 '12 at 23:54
  • As discussed on the mailing list, the console output will remain minimal. The webapp will, of course, let you visualize the data however you please (including columns in any order). It's worth noting that we've made a few changes that should make the interaction between the runner and the webapp a bit easier too, so there should be little reason to avoid the webapp. – gk5885 Dec 13 '12 at 01:01
  • Will there be documentation on using the webapp? I had crawled around on the caliper side but didn't find anything. – BeeOnRope Dec 13 '12 at 01:13
  • Also, do you accept patches? Your answer was ambiguous (neither yes or no, and not sure what mailing list entry to look at), but I assume it means that columns will continue to randomly change their ordering - I'm willing to do the work to fix that and submit a patch. – BeeOnRope Dec 13 '12 at 01:14
  • Yes, there will be documentation. More/better docs will be a focus at launch. Since this is a Google-owned project, we do accept patches, but there's a bit of a process to go through to. As far as columns go, it's not that "fixing" it is hard, but that we have found that the console output does more harm than good. The version we're currently testing does not print the output to the console at all - just the % of trials completed. Nobody has complained… yet. :-) – gk5885 Dec 13 '12 at 05:32
  • I'm a bit confused. I use caliper to rapid iterate on different implementations of some small classes, making changes and testing their effect immediately. The console output is the only thing I use, and the only thing I really need. If it is removed by default, it would be great if there were at least an option to enable it via argument. I don't really need to upload my results to a webapp just to visualize runtime when I'm doing this modify - compile - benchmark iteration. – BeeOnRope Dec 13 '12 at 21:51
  • This methodology has been tested at Google for everything from build output to JUnit test results to profiling data. Try it before you dismiss it. – gk5885 Dec 14 '12 at 09:19
  • I'm using it actively now (not 1.0, but 0.5rc1), and not dismissing it. I find great utility in the console output, and hope that we at least have the option of keeping it - horses for courses and all that. Console output is completely orthogonal in any case - it can be included without harming any of the other use cases. Of course, I can re-implement it locally, but having it out of the box would be ideal. – BeeOnRope Dec 14 '12 at 20:39
  • Is the webapp local, or are you referring to the hosted appspot one? – BeeOnRope Dec 14 '12 at 21:01
  • Thanks. Maybe I will get over my fear of it and try it out. Looking forward to 1.0. – BeeOnRope Dec 15 '12 at 00:31
  • Just [cross-referencing](http://stackoverflow.com/a/13887701/149138) another use case for console output - easy copy/paste into SO replies. – BeeOnRope Dec 15 '12 at 03:12
  • That is a perfect example of the deficiency of the console output. There is so much information missing from that bit of text about the JVM, the host machine, the instrument configuration, etc. that I would never, ever try to base a decision based on that alone. You can paste links into SO too. :-) – gk5885 Dec 15 '12 at 07:05
  • Something very close to 1.0 feature-wise is in HEAD. Feel free to check it out and give it a try. Right now I'm just fixing bugs, improving UI and writing documentation in preparation for the release. – gk5885 Feb 03 '13 at 16:35
  • Should just be mvn install. – gk5885 Mar 15 '13 at 14:13
0

According to this answer to my question, it's "coming very, very soon".

maaartinus
  • 44,714
  • 32
  • 161
  • 320