Issue #39 resolved

Add simple timing functionality.

David Williams
created an issue

Now that PolyVox has basic logging functionality it might be useful to add a simple timing facility. This would be useful for some profiling purposes. Under GCC it could probably use std::chrono and under Visual Studio it cold use the windows high performance counter.

Comments (13)

  1. David Williams reporter
    • changed version to 0.3

    I'd quite like to get this in for 0.3 because it will help me evaluate the LargeVolume performance, and it will also tie in nicely with the logging system (function timings can be measured and written to log trace).

    Matt Williams - If you want you can implement the Linux side of this with C++11's std::chrono, provided it's supported by the compilers we need? It's not supported by Visual Studio so I'll write a windows version myself.

    We could also just return '0' for the time on platforms which are too hard to support...

  2. Matt Williams

    It makes sense as a feature. I would note though that in the tests at the moment , some of them are using Qt's QBENCHMARK macro. For example here. This runs and times the block of code inside and if it's really quick will run it multiple times to get an average. However, it only works on blocks like that and obviously only works in the tests since it requires QTest. You can see this by directly running a test like:

    $ tests/TestCubicSurfaceExtractor
    ...
         3,343 msec per iteration (total: 3343, iterations: 1)
    ...
    

    Perhaps we want more than this and more control in which case putting together something simple with std::chrono makes a lot of sense. I guess you're thinking of something to go in Impl with basic start() and stop() functions?

    It looks like std::chrono is in VS 2012 and above. For earlier versions, there's always Boost.Chrono perhaps?

    Are you thinking that this will stay part of the tests and example framework or would it be integrated and exposed as part of PolyVox such that the average user will have access to it?

  3. David Williams reporter

    I'm mostly interested in providing function timing information in logs when logging is set to the most detailed level. This would only be for a few select functions, for example, when the LargeVolume pages data to disk it might be interesting to know how long this has taken, and how much of it was spent performing compression vs. disk access.

    It's basically a crude form of profiling, but in many cases it is easier than real profiling. PolyVox is wrapped in Cubiquity, Cubiquity is made into a .dll, and this .dll is invoked from .Net code in Unity which makes attaching a real profiler quite difficult. Some basic feedback would be useful.

    I think it would be a very simple class. Perhaps the constructor starts the timer, and then it just needs an elapsed() method? It's not really intended for user code but I suppose there's no harm in exposing it. A simple cross-platform timer can be a useful thing to have.

    It can ignore complex isues like whether it should measure 'real' time or processor/core time, and whether thread switches have occured. It's really just to give an idea. I think it should have at least millisecond precision though.

    On Windows I will implement this with: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx

  4. Matt Williams

    Ok, makes sense. I figured it would link in with the logging. I can handle setting up the std::chrono stuff for Linux, sure.

    I also agree that it would be nice to get this in for 0.3.

  5. Matt Williams

    I'll have a look at implementing a std::chrono etc. version for GCC when I get a chance. chrono is available in MSVS 2010 and above too so we might want to use it too there?

  6. David Williams reporter

    Sounds good. For VS2010 I don't think it really matters which implementation we use, but the one I committed last night will be removed for PolyVox 0.4 anyway once we are only targeting VS2010 and up.

  7. Matt Williams

    I've put together a simple implementation using std::chrono. It compiles fine on GCC 4.4 but it is not available on GCC 4.3. Currently 4.3 is our minimum supported version so this would increase it. I don't think this is a problem as 4.4.0 came out in 2009 so we're still supporting the last four years of compilers. I guess we're going to need at least 4.4 anyway at some point as that's when a good amount of the C++11 standard library got included (e.g. some threading).

  8. Matt Williams

    Ok, I've committed this as f81b42747 so it should work. It will almost certainly break the build machine tonight as GCC 4.3 won't work with it. Hopefully GCC 4.4 will be fine. If 4.3 breaks then I'll remove it from the build machine.

  9. David Williams reporter

    Looks good (and cleaner than the QueryPerformanceCounter version). The build machine does indeed seem to be failing on GCC 4.3 so I guess you can remove this and then close the issue.

  10. Log in to comment