Zam*_*son 5 c++ unix winapi logging timestamp
在我对系统进行了分析和分析之后,我得出的结论是,系统的记录组件是众多瓶颈之一,约占总运行时间的约17% - 记录了很多东西.
其中,记录器消耗的大约5%的时间与以下格式在ascii中生成日期/时间戳相关:YYYYMMDD HHMMSS.fff - 我们大致记录每秒约700k行.(大约700K x(localtime和gettimeofday)每秒呼叫)
我想知道SOERS有什么技术可以有效地制作时间戳.
跨平台解决方案将受到欢迎.
注1:我们查看了Boost.datetime - 它很棒,但对我们的需求来说有点太慢了,std :: chrono是一个完美的解决方案,但遗憾的是我们必须支持pre c ++ 11编译器.
注2:我们实现了一个简单的优化,它只计算每24小时一个日期部分(yyyymmdd),因此每行只有1个gettimeofday调用 - 虽然没有多大帮助.
如果您可以选择使用 C++11，则应该查看std::chrono。
否则，优化将取决于您需要的分辨率。我想问您是否绝对需要日志记录时间戳，或者带有序列信息的偶尔时间戳是否可能有用？
例子：
<timestamp1> <seq_num_0> ...
<timestamp1> <seq_num_1> ...
....
<timestamp1> <seq_num_n-1> ...
<timestamp2> <seq_num_0> ...
在我看来，你有两个问题：
我将使用基于计时器的系统每毫秒更新两次时间戳，并在更新之间重复使用它。然后，我将确保您的代码运行的系统的时钟与原子钟同步。您生成时间戳两次，以尝试补偿底层操作系统计时器机制的不稳定。
我不认为你能得到比这更好的了。
编辑：实际上，你可以。确保仅在时间戳字符串发生更改时对其进行格式化。如果您可以保证条目按照它们进入的顺序记录，您也不需要序列号。考虑到这两个假设，您的日志记录问题现在减少到连接和写出两个字符串的速度。
更新 2：如果 BOOST 不合适并且无法使用 C++11，则可以归结为：
假设 I/O 不是您的瓶颈，那么您的问题只不过是快速字符串连接之一。