Bencher

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        using Devel::Size. The measurement is done once per item when it is
        testing the code. See also: "with_args_size".

    *   with_process_size (bool)

        Include some memory statistics in each item's result. This currently
        only works on Linux because the measurement is done by reading
        "/proc/PID/smaps". Also, since this is a per-process information, to
        get this information each item's code will be run by dumping the
        code (using B::Deparse) into a temporary file, then running the file
        (once per item, after the item's code is completed) using a new perl
        interpreter process. This is done to get a measurement on a clean
        process that does not load Bencher itself or the other items. This
        also means that not all code will work: all the caveats in "MULTIPLE
        PERLS AND MULTIPLE MODULE VERSIONS" apply. In short, all outside
        data will not be available for the code.

        Also, this information normally does not make sense for external
        command participants, because what is measured is the memory
        statistics of the perl process itself, not the external command's
        processes.

    *   capture_stdout (bool)

        Useful for silencing command/code that outputs stuffs to stdout.
        Note that output capturing might affect timings if your benchmark
        code outputs a lot of stuffs. See also: "capture_stderr".

    *   capture_stderr (bool)

        Useful for silencing command/code that outputs stuffs to stderr.
        Note that output capturing might affect timings if your benchmark
        code outputs a lot of stuffs. See also: "capture_stdout".

    *   extra_modules (array of str)

        You can specify extra modules to load here before benchmarking. The
        modules and their versions will be listed in the result metadata
        under "func.module_versions", for extra information. An example to
        put here are modules that contain/produce datasets that get
        benchmarked, because the data might differ from version to version.

    *   env_hashes (array of hash)

        With this property, you can permute multiple sets of environment
        variables. Suppose you want to benchmark each participant when
        running under environment variables FOO=0, FOO=1, and FOO=2. You can
        specify:

         env_hashes => [
             {FOO=>0},
             {FOO=>1},
             {FOO=>2},
         ]

    *   runner (str)

        Set which runner to run the benchmark with. Either "Benchmark::Dumb"
        (the default), "Benchmark" ("Benchmark.pm", to get
        Benchmark.pm-style output), or "Benchmark::Dumb::SimpleTime" (to be
        able to run a code with only 1 or 2 iterations without warning,
        suitable if your code that runs for at least a few seconds and you
        don't want to wait for too long).

    *   on_failure (str, "skip"|"die")

        For a command participant, failure means non-zero exit code. For a
        Perl-code participant, failure means Perl code dies or (if expected
        result is specified) the result is not equal to the expected result.

        The default is "die". When set to "skip", will first run the code of
        each item before benchmarking and trap command failure/Perl
        exception and if that happens, will "skip" the item.

        Can be overriden in the CLI with "--on-failure" option.

    *   on_result_failure (str, "skip"|"die"|"warn")

        This is like "on_failure" except that it specifically refer to the
        failure of item's result not being equal to expected result.

        The default is the value of "on_failure".

        There is an extra choice of `warn` for this type of failure, which
        is to print a warning to STDERR and continue.

        Can be overriden in the CLI with "--on-result-failure" option.

    *   before_parse_scenario (code)

        If specified, then this code will be called before parsing scenario.
        Code will be given hash argument with the following keys:
        "hook_name" (str, set to "before_gen_items"), "scenario" (hash,
        unparsed scenario), "stash" (hash, which you can use to pass data
        between hooks).

    *   before_parse_participants (code)

        If specified, then this code will be called before
        parsing/normalizing participants from scenario. Code will be given
        hash argument with the following keys: "hook_name", "scenario",
        "stash".

        You can use this hook to, e.g.: generate participants dynamically.

    *   before_parse_datasets (code)

        If specified, then this code will be called before
        parsing/normalizing datasets from scenario. Code will be given hash
        argument with the following keys: "hook_name", "scenario", "stash".

        You can use this hook to, e.g.: generate datasets dynamically.

    *   after_parse_scenario (code)

        If specified, then this code will be called after parsing scenario.
        Code will be given hash argument with the following keys:
        "hook_name", "scenario" (hash, parsed scenario), "stash".

    *   before_gen_items (code)



( run in 0.586 second using v1.01-cache-2.11-cpan-71847e10f99 )