- changed status to open
- removed comment
TimerReport: Allow user to disable scheduled function timer table
Issue #311
closed
Now that TimerReport has several options for outputting timer data, the old-style table of schedule timers on standard output is often no longer needed, and takes up a lot of space in standard output. The attached patch provides a boolean parameter, TimerReport::output_schedule_timers=yes/no, defaulting to "yes" to maintain the current default behaviour. Users who want to use the "top timers" output instead now have the option to disable the scheduled function timer table.
Keyword: TimerReport
Comments (9)
-
reporter
-
- removed comment
I usually set the option
TimerReport::out_filename = "TimerReport"
to redirect this output into files. This has the added advantage that it provides timing information for all processes, which can be very useful -– timing information from a single process only is misleading and should probably be disabled by default.
To avoid confusion, all parameters that influence the schedule timers should have similar names. Your new parameter is called output_schedule_timers. Do you want to rename out_filename as well, so that it has "schedule" in its name?
Another way would be to handle screen output and file output for schedule timers via separate parameters. The new boolean decides on screen output, and the file name decides only on file output; an empty file name disables file output instead of enabling screen output.
-
reporter
- removed comment
I used to redirect output to files, but this leads to quite large files, and one per process, which is not good for very large jobs. The output format of the cactus schedule timer files is not machine-readable anyway, and so is pretty useless in comparison to the other formats.
If I rename the existing parameter, this could break existing parameter files, which doesn't seem like a good idea.
-
- removed comment
This thorn has gained many new capabilities in the recent past. I think it is time to have this reflected in the parameter names, which are currently confusing. Personally I would not mind changing parameter names, I rather think it has become necessary to do this.
-
- removed comment
Replying to [comment:4 eschnett]: I agree that changing the parameter names now would improve the thorn down the road, and I would accept the little "problems" right now.
-
reporter
- removed comment
We can provide a parameter with the new name, and keep the old ones, and if the user attempts to use them, the run should still work but give a big warning that the user can't miss. The parameters would then be removed at the next release (i.e. autumn 2011). It would be good if Cactus had a mechanism for marking parameters as deprecated to avoid having to implement this logic every time we change parameter names or meanings.
-
- removed comment
I suggest to apply Ian's patch now, and to add a brief comment to the parameter file that we may change the parameter names at some point.
-
- changed status to resolved
- removed comment
Applied.
-
- edited description
- changed status to closed
- Log in to comment
