On Wed, May 8, 2013 at 2:13 PM, Stephan Beal <[email protected]> wrote:
> On Wed, May 8, 2013 at 1:04 PM, Lluís Batlle i Rossell > <[email protected]>wrote: > >> Most of our delays come from fs operations, and they aren't reflected in >> that >> calculation. And I can't find how to get the 'real time' spent in the >> server. >> >> Can this be done with the current th1? >> > > i added something similar to this for the JSON API internals but don't > remember off-hand the internals APIs and such. It would, however, "almost > certainly" be no problem to stuff that data into the th1 interpreter. i'll > take a look at it in the next 48 hours or so (tomorrow's a holiday here). > Hi, Lluis, i've taken the json-specific timer code and added it to the fossil "util" API (util.c), but before committing it i found, in th_main.c, some nicer timing functionality which i would prefer to steal. So i then removed my impl and copied/refactored the th_main.c bits into util.c to give us microsecond-accurate timer. fossil_timer_start(); ... sqlite3_uint64 end = fossil_timer_stop(); fossil_timer_end() returns the number of uSec since start() was last called. Currently it will "stack" up to 10 timers (pushed/popped via start()/stop()), but before i commit it i want to play with start() returning and ID and end() taking an ID, as opposed to requiring matching pairs, e.g.: int timer = fossil_timer_start(); ... sqlite3_uint64 end = fossil_timer_fetch( timer ); However... for most operations the timer is telling me that 0 uSecs have passed. i can reliably get a valid time from long-running commands (e.g. fossil rebuild or even fossil dbstat) but not really fast one (e.g. fossil version). Once i am convinced that this is working okay i'll get it checked in. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
