Pull Request on 2025年12月24日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。

目次

  1. #122706 Use QueryUnbiasedInterruptTime instead of GetTickCount64 to allow more responsive Windows apps when they opt-in

#122706 Use QueryUnbiasedInterruptTime instead of GetTickCount64 to allow more responsive Windows apps when they opt-in

  • 作成者: @tannergooding
  • 作成日時: 2025年12月22日 20:19:50(UTC)
  • マージ日時: 2025年12月24日 06:19:44(UTC)
  • ラベル: area-System.Threading breaking-change needs-breaking-change-doc-created

概要

WindowsでのタイマーAPI実装をGetTickCount64からQueryUnbiasedInterruptTimeに変更し、スリープ・休止時間を除外してタイマー応答性を向上させます。これにより、Windows上のEnvironment.TickCount64の動作がUnix系プラットフォーム(Linux/macOS)と一貫性を持つようになり、アプリケーションがタイマー精度を向上させるためのオプト設定(例：timeBeginPeriod)に対応可能になります。

変更内容

  • Environment.Windows.cs: QueryUnbiasedInterruptTime APIの呼び出し実装を追加
  • Interop.QueryUnbiasedInterruptTime.cs: P/Invoke定義を拡張
  • TimerQueue.Windows.cs: Windows固有の実装を削除し、汎用実装に統一
  • Timer.cs: タイマー初期化ロジックを簡素化
  • gcenv.windows.cpp: GC環境設定でのタイマー処理を更新
  • Unix/Browser/Wasi実装: 一貫性向上のため整理

パフォーマンスへの影響

  • QueryUnbiasedInterruptTimeはGetTickCount64と比べて約1.5倍遅い(1.5ns vs 1.0ns)ですが、ナノ秒単位の差であり実用上は無視できます
  • キャッシュ値の特性上、どちらを使用してもミリ秒単位のクエリより頻繁に呼び出すことはなく、実際のアプリケーション性能への影響はありません
  • より高精度が必要な場合はQueryUnbiasedInterruptTimePrecise(約18ns)やQueryPerformanceCounter(約18ns)も提供

関連Issue

破壊的変更ドキュメント: https://github.com/dotnet/docs/issues/50755

その他

破壊的変更: この変更はEnvironment.TickCountとEnvironment.TickCount64の動作を変更します

  • 旧動作: スリープ/休止時間を含む、10-16ms(通常15.5ms)の固定精度
  • 新動作: スリープ/休止時間を除外、システム割り込みタイマー周波数に応じた精度(1ms以下も可能)

アプリケーション開発者は、スリープ時間の包含を前提にしたタイミング計算がある場合、ロジックの見直しが必要です。