Среда. TickCount по сравнению с DateTime. Теперь
8 ответов
Используйте класс Секундомера. На MSDN существует достойный пример: http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx
Stopwatch stopWatch = Stopwatch.StartNew();
Thread.Sleep(10000);
stopWatch.Stop();
// Get the elapsed time as a TimeSpan value.
TimeSpan ts = stopWatch.Elapsed;
Вы, вероятно, хотите System.Diagnostics.StopWatch .
Используйте
System.Diagnostics.Stopwatch
, Это имеет свойство, названное
EllapsedMilliseconds
Необходимо использовать Секундомер класс вместо этого.
Я использую Среду. TickCount, потому что:
- класс Секундомера не находится в Компактной Платформе.
- Секундомер использует тот же базовый механизм синхронизации в качестве TickCount, таким образом, результаты больше не будут или менее точны.
- всеобъемлющая проблема с TickCount вряд ли будет колоссально поражена (необходимо было бы оставить компьютер, работающий в течение 27 дней, и затем попытаться измерить время, когда просто, оказывается, охватывает всеобъемлющий момент), и даже если бы Вы действительно поражали его, то результатом был бы огромный отрицательный отрезок времени (таким образом, это отчасти выделилось бы).
Однако я также рекомендовал бы использовать Секундомер, если это доступно Вам. Или Вы могли занять приблизительно 1 минуту и записать подобный Секундомеру класс, который обертывает Среду. TickCount.
BTW, я ничего не вижу в документации Секундомера, которая упоминает всеобъемлющую проблему с базовым механизмом таймера, таким образом, я не был бы удивлен вообще найти, что Секундомер страдает от той же проблемы. Но снова, я не провел бы времени, волнуясь об этом.
Я собирался сказать, обертывают его в класс секундомера, но Grzenio уже заявил правильную вещь, таким образом, я дам ему рост. Такая инкапсуляция факторизует решение, относительно которого путь лучше, и это может измениться вовремя. Я не забываю потрясаться в том, как дорогой это может получать время в некоторых системах, также - одно место, которое может реализовать лучшую технику, может быть очень важным.
Для одноразовой синхронизации еще более просто записать
Stopwatch stopWatch = Stopwatch.StartNew();
...dostuff...
Debug.WriteLine(String.Format("It took {0} milliseconds",
stopWatch.EllapsedMilliseconds)));
, я предположил бы, что колоссально маловероятный перенос в TickCount является еще меньшим количеством беспокойства о StopWatch, учитывая, что поле ElapsedTicks является длинным. На моей машине StopWatch является высоким разрешением, в 2.4e9 галочки в секунду. Даже на том уровне, это приняло бы 121 год для переполнения поля галочек. Конечно, я не знаю то, что продолжается под покрытиями, поэтому возьмите это с мелкой частицей соли. Однако я замечаю, что документация для StopWatch даже не упоминает всеобъемлющую проблему, в то время как документ для TickCount делает.
Почему вас беспокоит опрокидывание? Пока измеряемая продолжительность составляет менее 24,9 дней и вы рассчитываете относительную длительность, все в порядке. Не имеет значения, как долго работает система, если вы заботитесь только о своей части этого времени работы (в отличие от прямого выполнения сравнений «меньше или больше» в начальной и конечной точках). Т.е. это:
int before_rollover = Int32.MaxValue - 5;
int after_rollover = Int32.MinValue + 7;
int duration = after_rollover - before_rollover;
Console.WriteLine("before_rollover: " + before_rollover.ToString());
Console.WriteLine("after_rollover: " + after_rollover.ToString());
Console.WriteLine("duration: " + duration.ToString());
правильно печатает:
before_rollover: 2147483642
after_rollover: -2147483641
duration: 13
Вам не нужно беспокоиться о знаковом бите. C #, как и C, позволяет процессору справиться с этим.
Это обычная ситуация, с которой я уже сталкивался раньше при подсчете времени во встроенных системах. Я бы никогда не сравнивал, например, beforerollover