|
Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/ Set by moderator on 25 May 2014. |
|||
| Util | Understandable! I had to go offline before you came back. We can just talk in #parrot in the morning. Thanks for attending! | 03:30 | |
|
07:33
basiliscos joined
12:13
ilbot2 joined
|
|||
| moderator | Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/ | ||
|
13:25
bluescreen joined
13:54
basiliscos joined
14:10
rurban1 joined
14:59
bluescreen joined
16:22
Chirag joined
|
|||
| Chirag | Util: Thanks! I will ask if I face issues with perl versioning | 16:37 | |
| rurban | Chirag: How is it going? | 16:40 | |
| Chirag | Hey! I am testing commits from RELEASE 2.7 - 2.8 to identify bad commits... my machine is really slow so havent completed bench on all of them as yet | 16:42 | |
| Writing the report now | |||
| blog* | |||
| rurban | But have you got a few good numbers already < 1% | 16:44 | |
| or do the seconds look unreliable? | 16:45 | ||
| Chirag | oops.. my bad I thought I was replying to Util | ||
| haven't really analyzed all of them... just glanced over them | |||
| but they look reliable | 16:46 | ||
| I stopped at 1174be4513d244c8e3102cdf280d0e6d1c89e341 .. which is still part of 2.7 | 16:47 | ||
| rurban | good | ||
| Chirag | let me put the data on a gist | 16:48 | |
| we can analyze that and will put my machine on another overnight run | |||
| rurban | yes. I'm a bit worried that your data will be as useless as mine | 16:50 | |
| And I cannot do more benchmarks until Friday, because I'm now release testing B::C | 16:51 | ||
| Chirag | oh.. shouldn't we be looking for >1%? | 16:52 | |
| gist.github.com/ZYROz/457b89653f27127fee4b | |||
| rurban | huh, you got one 16% spike. numbers look better than mine. I'll filter out >1% to get better results. | 16:56 | |
| Chirag | how did you analyze it that way? | 16:58 | |
| rurban | egrep "^tag=|seconds time elapsed" log.bench-chirag-2.7-2.8 | perl -lane'BEGIN{$/="tag="}; $F[0]=~s/RELEASE_//; $F[0]=~s|rurban/|0|; print "$F[0]\\t$F[1]\\t$F[7]" if $F[1]' > log.bench-chirag-2.7-2.8.data | 17:00 | |
| the 14-15s parts are worrying me. maybe the 34s tests actually threw exceptions? | 17:02 | ||
| Chirag | but I had made sure it printed everything | 17:03 | |
| rurban | can you check some >30s manually if they run properly? | ||
| Chirag | sure | ||
| rurban | github.com/parrot/parrot-bench/blo...7-2.8.data | 17:04 | |
| You only got a 1GHz machine. I've got 3GHz. that's why yours hould be ~3x slower. 34s makes sense | 17:06 | ||
| So the <20s runs do look suspicious | |||
| Chirag | I ll check those too | 17:07 | |
| rurban | only 1-3 please | ||
| I'll filter the <30s out I guess | |||
| egrep "^tag=|seconds time elapsed" log.bench-chirag-2.7-2.8 | perl -lane'BEGIN{$/="tag="}; $F[0]=~s/RELEASE_//; $F[0]=~s|rurban/|0|; print "$F[0]\\t$F[1]\\t$F[7]" if $F[1] and $F[1]>30.0' > log.bench-chirag-2.7-2.8.data.1 | 17:08 | ||
| egrep "^tag=|seconds time elapsed" log.bench-chirag-2.7-2.8 | perl -lane'BEGIN{$/="tag="}; $F[0]=~s/RELEASE_//; $F[0]=~s|rurban/|0|; print "$F[0]\\t$F[1]\\t$F[7]" if $F[1] and $F[1]>30.0 and $F[7] =~ /^0\\./' > log.bench-chirag-2.7-2.8.data.1 | 17:09 | ||
| Chirag | 73/150 .. remaining suspicious? | 17:12 | |
|
17:18
rurban1 joined
|
|||
| Chirag | the 34.* seem to produce similar data .. checking <20 | 17:22 | |
| rurban | github.com/parrot/parrot-bench/blo....7-2.8.png | ||
| so there are 2 spikes to investigate | 17:23 | ||
| but not really interesting. not the big slowdown so far | |||
| Chirag | gc4729e2 | 17:24 | |
| hmm.. what about <20s ones? | |||
| rurban | remove the first g and use it like git show c4729e2 | ||
| Chirag | ok | 17:25 | |
| rurban | c4729e2 is just a whitespace fix | ||
| no idea about the <20s yet | |||
| Chirag | then the one before - 4585a67 | ||
| confirmed - they are incorrect.. for instance, b984a2c\t= 14.948903834 , now 34.880759557 | 17:27 | ||
| rurban: So, should I retest <20s commits again? followed by the remaining commits? | 17:45 | ||
| rurban | I see no benefit for retesting. you should rather find the slow down further the road towards 2.7. 2.7.0 should be something like 33s and suddenly it became slower (34s) | 18:09 | |
| oops, wrong channel, let's switch over to #parrot | |||
