On Thu, Jul 15, 2010 at 03:25:39PM +0200, Fabian Groffen wrote:
> Changeset: dfcab86b0cb0 for MonetDB
> URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=dfcab86b0cb0
> Modified Files:
>       clients/ChangeLog
>       clients/src/mapiclient/mclient.mx
> Branch: default
> Log Message:
> 
> implement timing per server response for results and updates for SQL formatter
> 
[...]
> diff -r df828b8fc84c -r dfcab86b0cb0 clients/src/mapiclient/mclient.mx
> --- a/clients/src/mapiclient/mclient.mx       Thu Jul 15 15:09:22 2010 +0200
> +++ b/clients/src/mapiclient/mclient.mx       Thu Jul 15 15:11:07 2010 +0200
> @@ -342,6 +342,26 @@
>       }
>  }
>  
> +static char htimbuf[32];
> +static char *
> +timerHuman()
> +{
> +     long t = t1 - t0;
> +
> +     if (t / 1000 < 950) {
> +             snprintf(htimbuf, 32, "%ld.%03ldms", t / 1000, t % 1000);
> +             return(htimbuf);
> +     }
> +     t /= 1000;
> +     if (t / 1000 < 60) {
> +             snprintf(htimbuf, 32, "%ld.%02lds", t / 1000, t % 1000);
> +             return(htimbuf);
> +     }
> +     t /= 1000;
> +     snprintf(htimbuf, 32, "%ldm %lds", t / 60, t % 60);
> +     return(htimbuf);
> +}
> +
>  /* The Mapi library eats away the comment lines, which we need to
>   * detect end of debugging. We overload the routine to our liking. */
>  
[...]

While I like the new timing feature as well as the convenient formatting for
human readability, I am wondering about two potential changes / extensions:

(a) While the time formatting is convenient for human readbility, it might
    be less convenient for automatic (post-)processing, e.g., creating
    performance figures. For that, plain unformatted microseconds (in
    addition to the human-readable format) might be more convenient.

(b) The "old" (still existing) "Timer" information is sent to stderr,
    thus, one can seem the Timer output without the need to grep through
    (potentially large) output, e.g., by simply redirecting the output to a
    file or even /dev/null --- obviously, aligning stderr & stdout in case
    of large multi-query scripts is then left to the user.
    The new timing output goes (together with the queries status summary
    like how many result tuples were produced) to stdout (only).

(c) As the announcement (changelog) says, the new timing output is only
    produced with the "sql" formatter (i.e., not with, e.g., "raw" or
    "test", and hence, also not by default with `-s <sql-statement>` (unless
    one explicitly requests `-f sql`).

For (a) & (b) would it be an option to consider to also send the plain
unformatted times in microseconds to stderr to (better) support automatic
post-processing of the timings?

To cover also (c), we could consider doing that with all formatters, not
only with "sql".

... just some ideas to think about and discuss ...

Stefan

-- 
| Dr. Stefan Manegold | mailto:stefan.maneg...@cwi.nl |
| CWI,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: +31 (20) 592-4212       |
| The Netherlands     | Fax : +31 (20) 592-4199       |

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Monetdb-developers mailing list
Monetdb-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Reply via email to