TimerReport: Allow user to disable scheduled function timer table

Create issue
Issue #311 closed
Ian Hinder created an issue

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)

  1. Erik Schnetter
    • 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.

  2. Ian Hinder 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.

  3. Erik Schnetter
    • 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.

  4. Frank Löffler
    • 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.

  5. Ian Hinder 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.

  6. Erik Schnetter
    • 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.

  7. Log in to comment