You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(16) |
2
(22) |
3
(23) |
4
(12) |
5
(24) |
6
(28) |
7
(16) |
|
8
(3) |
9
(2) |
10
(9) |
11
(22) |
12
(19) |
13
(19) |
14
(15) |
|
15
(10) |
16
(23) |
17
(27) |
18
(31) |
19
(26) |
20
(19) |
21
(17) |
|
22
(6) |
23
(4) |
24
(3) |
25
(14) |
26
(1) |
27
(20) |
28
(14) |
|
29
(10) |
30
(26) |
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2013-09-09 21:32:22
|
On Sun, 2013-09-08 at 23:34 +0200, Florian Krohm wrote: > The problem with this approach is that you don't notice performance > degradation that creeps in on you. Say 1% a day for several days in a > row. 1% degradation would not get any attention but when it accumulates > over time, it should. > What if we run perf every day and send the results to e.g > pe...@va...? Whenever mail is received at that address a little > script runs that reads the perf results and collects them in some light > weight "data base" that we could look at at valgrind.org/perf. It could > be as simple as a HTML table (per platform) with one row per day that > shows, for each tool, the difference to the previous run and the > difference to some base line run. > Yes, this is more work to set up than just sending the results to the > developers list. But the results might get more attention that way. Yes, effectively, gradual small performance degradation is not easy to detect with a daily difference. So, maybe the valdev archive can be seen as the DB. I think you started to write a script to handle archived test results and make an html page from it. A colleague has started enhancing this script (e.g. taking some other ideas from what wine does for their night tests results). So, handling the perf results is another enhancement to do. (that is a hint for my colleague :). > > > > So, a few questions: > > 1. how much --reps ? Is 3 ok ? > > I typically use --reps=5 but if I had a better handle on variations or a > better tool to measure runtime than "time" less repetition mught be > possible. > > > 2. do we run perf for all tools ? > > or only for non-experiment tools ? > > or for even less tools (only none and memcheck ?) > > Non-experimental tools should be enough. Skipping the exp tools does not change a lot the time it takes. So, --reps=3 => 1 hour on a fast computer, 3 hours on a slow pentium. If we take --reps=5, this is respectively 1h40 and 5 hours. Maybe we could have the "conf" allowing to specify: to run perf test y/n the --reps= value with comparison with the previous day y/n Just having the first 2 configured allows the "valdev" scanner to produce the evolution of performance, the 3rd allows to quickly see a daily perf difference Philippe |
|
From: Mark W. <mj...@re...> - 2013-09-09 13:17:39
|
On Fri, 2013-09-06 at 11:15 +0200, Julian Seward wrote: > >> Would people like to meet during that conference? > > I would. Sounds like a good idea. I plan to attend. I'll sent a request for a devroom to the Fosdem organizers. We should hear back around October 1st whether there is a room available for us. Then we can do some planning on who wants to talk on what and when. In general Fosdem devrooms can use whatever form people want. Formal presentations, hackatons, panel discussions or just an open discussion. > += discuss release/bugfixing strategy/policy? Hopefully I can be of some help with this. The current Fedora package of valgrind contains a lot of backports (currently 50!) of functionality already in valgrind svn trunk requested by users. It would probably be more efficient if I helped getting (some of) these into an upstream (minor) release. IMHO having a predictable time-base (minor) release of valgrind every couple of months would be very helpful. One reason for the many backports is that the next major release 3.9.0 keeps getting postponed. The trick of course is making sure these time-based releases are stable. How can we decide which feature is ready/stable enough when? It would be nice to invite other valgrind packagers and talk about how they handle releases, updates and patches. And how people are handling default (system wide) suppressions. Another idea is to invite some of the hackers of tools that valgrind interfaces with. It would be nice to discuss with GDB hackers how to make the valgrind gdbserver integration even smoother (they are working on support for one gdb process to talk to multiple gdbservers, and the valgrind gdbserver could implement the multiprocess aware extensions that might make starting processes under valgrind from gdb easier). The Eclipse Linux Tools Project has valgrind support http://www.eclipse.org/linuxtools/projectPages/valgrind/ They might be able to give feedback on how to make it easier to integrate things. There are probably other projects with which we could discuss integration points. Cheers, Mark |