localdate转date时区问题_mktime性能问题

75 阅读 0 评论 50 点赞

我是靠谱客的博主坚强烧鹅，最近开发中收集的这篇文章主要介绍localdate转date时区问题_mktime性能问题，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

最近项目在使用mktime时遇到了一个性能问题。

先描述一下项目是怎样使用mktime：通常情况下有这样的一种需求，就是通过输入年月日时分秒，来获取时间戳，对应的Python代码可以写成如下形式：

def datetime_to_ts(year, month, date, hour=0, minute=0, second=0):
    dt = datetime.datetime(year, month, date, hour, minute, second)
    return time.mktime(dt.timetuple())

上面这种情况下，性能上是没有问题的，直到我们加入了时区的功能：

class UTC(datetime.tzinfo):
	"""UTC"""
	def __init__(self,offset = 0):
		self._offset = offset

	def utcoffset(self, dt):
		return datetime.timedelta(seconds=self._offset)

	def tzname(self, dt):
		return "UTC +%s" % self._offset

	def dst(self, dt):
		return datetime.timedelta(seconds=self._offset)

def datetime_to_ts(year, month, date, hour=0, minute=0, second=0):
    dt = datetime.datetime(year, month, date, hour, minute, second, tzinfo = UTC(28800))  # 28800 = 东八区
    return time.mktime(dt.timetuple())

两种情况性能差非常大，如下测试，linux内核4.9，glibc版本2.24，CPU8core，16G内存，测试用例如下：

 for i in xrange(0, 10000):
     datetime_to_ts(2020,10,11)

测试结果如下：

# 有时区版本
> time python test.py
real	0m3.410s
user	0m3.340s
sys	0m0.020s

# 无时区版本
> time python test.py
real	0m0.056s
user	0m0.032s
sys	0m0.020s

运行时间差了70倍！

对两个代码的输出做了比较，发现加了时区后，datetime.timetuple函数输出的结果中tm_isdst=1:

time.struct_time(tm_year=2020, tm_mon=10, tm_mday=11, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=285, tm_isdst=1)

tm_isdst=1表示使用夏令时计算时间戳，但是如果系统配置是不支持夏令时的话，mktime的计算就会非常耗时。

具体是什么原因呢？具体要看mktime(3)的内部实现。

mktime的计算流程：

mktime的内部主要逻辑在__mktime_internal函数中，基本的思路如下：

输入的参数与 1970年1月1日0时0分0秒进行对比，计算一个偏移的时间戳t0

t0 = ydhms_diff (year, yday, hour, min, sec,
		   EPOCH_YEAR - TM_YEAR_BASE, 0, 0, 0, - guessed_offset);

基于t0，利用localtime(3)函数计算一个新的struct tm数据（这个数据是基于本地时区计算得到的），重新利用ydhms_diff函数，计算struct tm于t0的偏差，调整t0值

  for (t = t1 = t2 = t0, dst2 = 0;
       (gt = guess_time_tm (year, yday, hour, min, sec, &t,
			    ranged_convert (convert, &t, &tm)),
	t != gt);
       t1 = t2, t2 = t, t = gt, dst2 = tm.tm_isdst != 0)

举一个简单的例子，如果我们调用mktime输入的时间是 1970年1月1日0:0:0 ，那么在计算t0时，得到t0的值为0，但是在之后的for循环里面，ranged_convert中会调用localtime重新计算struct tm数据，因为我们处于东八区，计算的结果中tm_hour会等于8，因此我们会利用这个结构调整t0的时间偏移为-28800秒，此时gt=-28800。第二次for循环迭代，ranged_convert的输入参数从0变为-28800，此时计算的gt就和t保存一致了。因此，退出for循环。

如果没有DST（夏令时），整个mktime就基本完成了。但是，，，之后mktime会调用isdst_differ函数判断输入的dst flag与之前for循环计算的dst flag是否一致，如果不一致将会进入一个多次迭代的过程中。

  /* isdst是用户输入的tm_isdst：在我们的Python例子中等于1
     tm.tm_isdst是上面for循环的结果，在我们服务器系统上为0
     两个值不相等，进入if代码块
  */
  if (isdst_differ (isdst, tm.tm_isdst))
  {
      /* 以601200秒为步长找到一个dst=1的时间 */
      int stride = 601200;
      int duration_max = 536454000;
      int delta_bound = duration_max / 2 + stride;

      int delta, direction;

      /* 两层for循环， 从当前时间开始，以stride为步长左右移动计算localtime 
         如果按照香港时区Hong Kong，香港最后一次夏令时在1979年10月的样子
         对应的时间戳差不多308883600，如果从2020年10月11日的时间计算
         差不多要经过4000多次迭代
      */
      for (delta = stride; delta < delta_bound; delta += stride)
	for (direction = -1; direction <= 1; direction += 2)
	  if (time_t_int_add_ok (t, delta * direction))
	    {
	      time_t ot = t + delta * direction;
	      struct tm otm;
	      ranged_convert (convert, &ot, &otm);
	      if (! isdst_differ (isdst, otm.tm_isdst))
		{
		  /* We found the desired tm_isdst.
		     Extrapolate back to the desired time.  */
		  t = guess_time_tm (year, yday, hour, min, sec, &ot, &otm);
		  ranged_convert (convert, &t, &tm);
		  goto offset_found;
		}
	    }
   }

通过上面的代码注释，可以看到，如果mktime传入的dst=1，性能会大打折扣！

最后，附上一篇文章mktime函数性能分析，这篇文章对mktime做了全面的基准测试。

附录：