On 2010-07-16 16:27, Stefan Manegold wrote: > 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.
fflush(stdout); right before printing the time, then fflush(stderr); after. > 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 > -- Sjoerd Mullender
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
