GNOME Bugzilla – Bug 57464
no timer/profiler support in win32 for xsltproc.c
Last modified: 2009-08-15 18:40:50 UTC
In xsltproc.c the timing information is kept in an integer variable "msec". This causes information on fractions of a millisecond to be lost when it is rounded down. It might make more sense to use a double for time intervals. On win32 systems xsltproc.c does not provide any timing information because gettimeofday() does not exist on win32 systems and a macro rdefines it to an empty string. I have found the attached routine to be useful for getting accurate timing information on win32 systems. I'm using MSVC 6 SP 5 on Win 2k. This would also eliminate some tedious code for measuring time intervals from xsltproc.c. =========================================================== /* * elapsedtime.c: elapsed time in seconds * * Returns a double precision number for performance monitoring. * Use the difference in value between two calls to measure the * difference in seconds. On Unix systems resolution with * timeofday is in the microsecond range. */ #ifdef HAVE_SYS_TIME_H #include <sys/time.h> #endif #ifdef HAVE_UNISTD_H #include <unistd.h> #endif #ifdef WIN32 #ifdef _MSC_VER #include <windows.h> #define XSLT_USE_WIN32_PERFORMANCE_COUNTER #endif /* _MS_VER */ #else /* WIN32 */ #include <sys/time.h> #endif /* WIN32 */ double elapsedTimeSeconds(void) { #ifdef XSLT_USE_WIN32_PERFORMANCE_COUNTER BOOL ok; LARGE_INTEGER performanceCount; LARGE_INTEGER performanceFrequency; LONGLONG quadCount; LONGLONG quadFreq; ok = QueryPerformanceCounter(&performanceCount); if (ok == 0) return 0.0; quadCount = performanceCount.QuadPart; ok = QueryPerformanceFrequency(&performanceFrequency); if (ok == 0) return 0.0; quadFreq = performanceFrequency.QuadPart; return ( (double) quadCount) / ((double) quadFreq); #else struct time_val now; gettimeofday(&tv_now, NULL); return tv_now.tv_usec/1.0e6 + (double) tv_now.tv_sec; #endif }
Hum, first msec contains 100's of us and that resolution is enough for libxslt it seems. Second when it comes to this kind of computations I definitely don't want to use floating point, sorry that's not proper. Last I do want timestamping for the profiling computations, not delays. Using the program counter seems the right way to do things on Windows but I can't test them and the code you provide is too different from what I want to be able to reuse it as is. I may try to work this out, but providing a code fragment integrating in the #else HAVE_GETTIMEOFDAY of xsltTimeStamp() sounds a better idea if you want this feature to be added to libxslt. thanks, Daniel
Yes, xsltTimeStamp is a better place. I didn't know about it before. I think milliseconds is too coarse. For instance, on my 933 MHz W2k machine (or 800 Mhz Linux machine) xml document parsing takes less than 1 msec, so the reported time is 0. I bet "calibration" is always 0 (less than 1 ms). What do you think of changing the resolution of xsltTimeStamp from 1 ms to 0.01 mSec ? This would be ok up to about 6 hours before overflow. If you like this I could rewrite xsltTimeStamp to use performanceCounter on win2k and gettimeofday on those systems which have it. I could test it on a win2k MSVC 6 system and on a RedHat Linux 7.0 system. I'm not sure this is worth the trouble since all the messages where ms appears would have to be changed slightly. For instance, from prinf("...%d ms"...,elapsed) to printf("...%f ms", elapsed/1.0e5).
xsltTimeStamp resolution is actually 100us i.e. 0.1 ms so far this is sufficient. I would appreciate if you could provide a patch for this function supporting Windows performanceCounters. If you really feel the need for a finer grained resolution, fine, change xsltTimeStamp resolution to 10us but I'm afraid it will generate only noise in most cases. in a nutshell: patch welcome, thanks ! Daniel
Created attachment 749 [details] zip file with changes to xsltutils.* for timer support
Okay I have commited a change based on your patch, however I keep the sampling at 100us, and the calibration. There is platforms where gettimeofday() is far slower than on linux. Daniel
Okay, the Windows profiler should be part of 1.0.2 release, thanks, Daniel