Closed LiamDawe closed 8 years ago
According to my benchmarks, the error that is introduced by the way GLXOSD writes the log is measured in microseconds, which means that its impact on the data is negligible compared to external factors. That said, these numbers come from benchmarks done on an SSD and if you have a slow hard-drive this may lengthen each frame by a fraction of a millisecond, but that doesn't really bother me because compared to what a slow hard-drive can do to a game, the overhead GLXOSD introduces is negligible.
That's a real shame you see it that way, as I can't really use it for benchmarking in that case. Anything that can be avoided for benchmarking, should be.
The rest of the project is great though, but I would really like to see this, I imagine others would use it more if it was more accurate too.
Sorry, but in the context of 20 milliseconds, a few microseconds are just not visible on the scale.
I don't think this is worth stirring up the packaging soup right now, especially since I started looking into rewriting GLXOSD in something that doesn't carry library compatibility problems with it (I spent about 30% of development time battling libstdc++ compatibility problems). I'll add this to the new version's wishlist, but don't expect a new version for a while.
That's great you're thinking about it for future, as it's a muuuuuch nicer way to do it. Think also of SSD life span with it being spammed during a longer testing session, then multiply that by hundreds of tests.
It all adds up in the end :)
I added this feature in version 2.4.0.
Excellent, can't wait to try it. Could you update the website documentation for the mode? :+1:
Updated.
Forgot to leave a link for the lazy... Here is the documentation: http://glxosd.nickguletskii.com/usage.html#benchmarking
To make the benchmarking mode actually worthwhile, you should store the values in memory, and write to the file after, not during. This will make it more accurate, otherwise it's not going to give good readings in reality.