[Monetdb-developers] MonetDB: default - implement timing per server response for resu...

Sjoerd Mullender sjoerd at acm.org
Fri Jul 16 17:20:07 CEST 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://www.monetdb.org/pipermail/developers-list/attachments/20100716/4d8e958a/attachment.sig>


More information about the developers-list mailing list