孫景樂 王成華


摘要:該文針對時序數據的特點提出一種高效的時間轉化為字符串格式的算法,該文算法在時序數據場景下轉化效率是Linux系統API(strftime)的4倍以上,在極端非序列場景下也接近系統的API效率(0.986倍),綜合性能優于系統API,在日常開發過中可作為系統API的替代函數使用。
關鍵詞:時序數據;時間格式轉換;Linux? 系統;API;strftime
中圖分類號:TP311? ? 文獻標識碼:A
文章編號:1009-3044(2021)03-0127-02
1前言
在分散控制系統[1]以及其他監測系統中,時間戳是監測數據的重要屬性,且數據具有按照時間順序發生的特點[2-3]。Linux系統下,時間的完整格式一般由兩個32位的整數表示①,第一個整數表示距離1970年1月1日0時0分0秒的秒數[4],第二個整數表示相對于第一個數的微秒數。但是這種時間格式對于人類來說不直觀,在存入歷史庫或在界面顯示數據時,需要將整數格式的時間轉化為直觀的字符串格式。在Linux平臺下,系統API函數strftime[5]可以將時間轉化為字符串格式。雖然該函數已經過充分優化,具有較高的效率,但高頻率調用系統API函數會導致用戶CPU占用率和系統CPU占用率升高,極端情況下可達100%,導致系統不能正常運行。本文利用strftime函數,在轉化的機制上提出一種改進的時間轉換算法,時序場景下效率可提高4倍多。
2算法原理及實現邏輯
該算法與時序數據時間戳的特點密切相關,本算法充分利用了數據的時序性,并結合計算機數據處理的特性實現。
2.1 軟件開發過程的時間處理方法
當前主流的操作系統主要有Windows和Linux系統,兩種操作系統提供的日期時間表示方法思路也非常類似,都是通過使用整數表示距離某個歷史特定時刻的100納秒數或秒數。當在用戶界面顯示時間戳時,需要將時間的整數形式轉化為人類更容易理解的字符串格式,例如,“2020年6月10日 13:35:40.622”。Windows系統和Linux系統都提供從整數格式轉化為字符串格式的API函數。
2.2 時序系統的特點
在監測系統中,監測點數據一般都是按照時間順序周期采集,例如50毫秒采集一次或更長的間隔采集一次,所以在一秒之內,時間戳的秒級時間數值不變,僅毫秒和微秒在變化。例如,當前某監測點在“2020-6-6 18:30:12.100秒采集一次數據,后面每隔50毫秒采集一次數據,在[“2020-6-6 18:30:12.000”, “2020-6-6 18:30:13.000”)之間時間戳的秒都是”2020-6-6 18:30:12”,變化的僅僅是毫秒級別的時間,所以不需要對每個時間戳都調用系統API對時間戳進行轉化,可以充分前面的轉化結果,避免重復轉化,提高效率。特別在監測點數高達數十萬,甚至數百萬的大型系統中,一秒內會產生大量的數據,進行時間格式轉化的頻率非常高。
2.3? 高效算法的基本思路
根據時序數據的時間戳特點,提出了更高效的時間轉化算法,思路如下:
1)分配緩存空間,存放最近n(一般為n=2即可)秒時間內的轉化結果,存放數據包括秒數及對應的時間字符串;
2)針對當前要處理的時間戳,先在緩存中查找是否已經轉化過該時刻的秒數。如果已轉化,則直接利用轉化好的字符串與時間戳中小于秒的部分(毫秒或微秒等)進行字符串拼接,得到一個完整的字符串格式的時間戳;如果找不到,則調用系統API進行格式轉化,并將轉化結果替換掉緩存中最舊的轉化結果,然后拼接毫秒和微秒部分的字符串,最后輸出完整的時間字符串格式,算法的流程圖如圖1所示。
2.4 極端情況下的本文算法效率分析
該算法是根據時序數據的特點提出的,所以針對時序數據會有較高的效率。如果在極端非時序數據情況下,則需要對該算法的效率進行分析。所謂極端情況,即任意相鄰兩次的時間差都大于緩沖次數n,在緩沖區中不能找到已有轉化,所以每次轉化都需要調用系統API進行轉換。此時,本文算法的效率就退化為比直接調用系統API效率略低的算法。之所以比系統API效率低是因為快速算法比直接調用系統API多執行了在緩沖區查找轉化結果的過程。由于緩沖區次數n一般為2,所以查找時間非常短,所以即使在極端情況下,快速算法的效率也接近系統API的效率,后面的實驗數據也充分驗證了這一點。
4性能驗證
4.1實驗方案
實驗方案分為兩部分:一種是在時序數據環境下進行效率對比,另一種是在極端情況下進行效率對比。
1)時序數據場景下對比
因為該算法是與數據的時序性密切相關的,所以實驗過程中數據的變化也模擬了時序系統的特點。給定一個時間初始值t0(由秒和微秒兩部分組成),每間隔1秒,t0中的秒部分增加1秒,微秒的數值部分每執行一次轉化后都會發生變化。
2)極端非時序場景下對比
該情況下時間的秒數采用隨機產生的方法,新的時間能在緩存中找到的概率非常低,幾乎每次都需要調用系統API函數進行轉化。
4.2實驗環境
實驗環境是在VMWare虛擬機上的Linux操作系統(Ubuntu18),兩種算法都是在同一環境下比較,所以可以保證實驗結果的客觀性。
4.3實驗結果
實驗中分別調用系統API和本文算法進行時間格式轉化,在相同的運行環境下分別運行約10秒、20秒和30秒,統計兩個算法執行時間轉化的次數,計算每次的平均運行速度,最后在計算綜合平均速度進行比較,實驗數據如表1所示。
本文算法的三次綜合平均速度為:1036.5萬次/秒,系統API算法的三次綜合平均速度為238.9萬次/秒。實驗數據表明,本文算法的運行效率遠遠高于系統API算法的效率,大約是系統API算法的4.34倍。
非時序情況下,本文算法平均計算速度為235.6萬次/秒,是系統API效率的0.986倍,略低于系統API的效率。
5 總結
在具有時序特點的監控系統場景下將時間格式轉化為字符串格式,本文算法的效率是系統API函數(strftime)的4倍多;在極端情況下,本文算法的效率是系統API算法效率的0.986倍,效率基本相同。所以,在日常開發過程中,該快速算法完全可以用來替代直接調用系統API函數。
注釋:
不同的系統采用的時間機制不同,本文主要以Linux系統下的時間表示方法進行敘述.
參考文獻:
[1] 百度百科. 分散控制系統[EB/OL].[2020-08-04]. https://baike.baidu.com.
[2] 王紅濤,王志超,陳峰,等.基于時序數據庫的工業大數據應用研究[J].重型機械,2020(4):17-21.
[3] 林志達,張華兵,張今革.基于時序數據庫的監控數據存儲方法研究[J].電子元器件與信息技術,2020,4(1):73-74,100.
[4] 百度百科. unix時間戳[EB/OL].[2020-08-04]. https://baike.baidu.com.
[5] 小丁木. linux中常用時間和字符串之間相互轉化[EB/OL]. (2017-07-11)[2020-07-04]. https://www.cnblogs.com/xiaodingmu/p/7152396.html.
【通聯編輯:聞翔軍】