Comment puis-je obtenir le système Windows de temps avec milliseconde?

GetTickCount ne l'aurez pas fait pour vous.

Regarder dans QueryPerformanceFrequency /QueryPerformanceCounter. Le seul piège est ici de PROCESSEUR de mise à l'échelle, donc de faire votre recherche.

C'est une élaboration des commentaires ci-dessus pour expliquer certains des tenants.

Tout d'abord, le Fonction getsystemtime* les appels sont la seule Api Win32, la fourniture du système de temps. Cette fois a assez grossier granularité, comme la plupart des applications n'ont pas besoin les frais généraux nécessaires pour maintenir un niveau de résolution. Le temps est (probablement) stocké en interne comme un 64-bit nombre de millisecondes. L'appel de timeGetTime obtient le faible de l'ordre de 32 bits. L'appel de fonction getsystemtime, etc les demandes de Windows pour revenir à ce temps milliseconde, après la conversion en jours, etc et y compris le système de démarrage.

Il y a deux sources de temps dans une machine: le PROCESSEUR de l'horloge et d'un conseil d'administration de l'horloge (par exemple, l'horloge temps réel (RTC), Programmable compteurs d'Intervalle (la FOSSE), et la Haute Précision de l'Événement Timer (HPET)). Le premier a une résolution d'environ ~0.5 ns (2GHz) et le second est généralement programmables vers le bas pour une période de 1 ms (si les nouvelles puces (HPET) ont une meilleure résolution). Windows utilise ces périodiques tiques pour effectuer certaines opérations, y compris la mise à jour de l'heure du système.

Les Applications peuvent modifier cette période via timerBeginPeriod; toutefois, cela affecte l'ensemble du système. L'OS va vérifier /mettre à jour régulièrement des événements à la fréquence demandée. Sous faible charge du CPU /fréquences, il y a des périodes d'inactivité pour économiser l'énergie. À haute fréquence, il n'y a pas de temps pour mettre le processeur en état de faible consommation énergétique. Voir La Résolution Du Timer pour plus de détails. Enfin, chaque tick a des coûts et l'augmentation de la fréquence consomme plus de cycles de PROCESSEUR.

Pour une meilleure résolution temps, l'heure du système n'est pas maintenu à cette précision, pas plus que Big Ben a une seconde main. À l'aide de QueryPerformanceCounter(QPC) ou de la CPU tiques (rdtsc) peut fournir la résolution entre le système de tiques de temps. Une telle approche a été utilisée dans l'article de MSDN magazine Kevin cité. Bien que ces approches peuvent dérive (par exemple, en raison de la fréquence de mise à l'échelle), etc et, par conséquent, doivent être synchronisés à l'heure du système.

À partir de Windows 8, Microsoft a présenté la nouvelle API de commande GetSystemTimePreciseAsFileTime:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx

Malheureusement, vous ne pouvez pas l'utiliser si vous créer un logiciel qui doit aussi fonctionner sur les anciens systèmes d'exploitation.

Ma solution actuelle est comme suit, mais il faut être conscient que Le temps déterminé, il n'est pas exact, c'est seulement près du temps réel. Le résultat doit toujours être inférieur ou égal au temps réel, mais avec une résolution de l'erreur (à moins que l'ordinateur est en mode veille). Le résultat est une milliseconde. Mon objectif c'est assez exact.

void GetHighResolutionSystemTime(SYSTEMTIME* pst)
{
    static LARGE_INTEGER    uFrequency = { 0 };
    static LARGE_INTEGER    uInitialCount;
    static LARGE_INTEGER    uInitialTime;
    static bool             bNoHighResolution = false;

    if(!bNoHighResolution && uFrequency.QuadPart == 0)
    {
        //Initialize performance counter to system time mapping
        bNoHighResolution = !QueryPerformanceFrequency(&uFrequency);
        if(!bNoHighResolution)
        {
            FILETIME ftOld, ftInitial;

            GetSystemTimeAsFileTime(&ftOld);
            do
            {
                GetSystemTimeAsFileTime(&ftInitial);
                QueryPerformanceCounter(&uInitialCount);
            } while(ftOld.dwHighDateTime == ftInitial.dwHighDateTime && ftOld.dwLowDateTime == ftInitial.dwLowDateTime);
            uInitialTime.LowPart  = ftInitial.dwLowDateTime;
            uInitialTime.HighPart = ftInitial.dwHighDateTime;
        }
    }

    if(bNoHighResolution)
    {
        GetSystemTime(pst);
    }
    else
    {
        LARGE_INTEGER   uNow, uSystemTime;

        {
            FILETIME    ftTemp;
            GetSystemTimeAsFileTime(&ftTemp);
            uSystemTime.LowPart  = ftTemp.dwLowDateTime;
            uSystemTime.HighPart = ftTemp.dwHighDateTime;
        }
        QueryPerformanceCounter(&uNow);

        LARGE_INTEGER   uCurrentTime;
        uCurrentTime.QuadPart = uInitialTime.QuadPart + (uNow.QuadPart - uInitialCount.QuadPart) * 10000000 /uFrequency.QuadPart;

        if(uCurrentTime.QuadPart < uSystemTime.QuadPart || abs(uSystemTime.QuadPart - uCurrentTime.QuadPart) > 1000000)
        {
            //The performance counter has been frozen (e. g. after standby on laptops)
            //-> Use current system time and determine the high performance time the next time we need it
            uFrequency.QuadPart = 0;
            uCurrentTime = uSystemTime;
        }

        FILETIME ftCurrent;
        ftCurrent.dwLowDateTime  = uCurrentTime.LowPart;
        ftCurrent.dwHighDateTime = uCurrentTime.HighPart;
        FileTimeToSystemTime(&ftCurrent, pst);
    }
}

QueryPerformanceCounter() est construit pour la fine résolution du timer.

C'est la résolution la plus élevée de la minuterie que le système a à offrir, que vous pouvez utiliser dans votre code d'application pour identifier les goulots d'étranglement des performances

Ici est une simple application pour C# devs:

    [DllImport("kernel32.dll")]
    extern static short QueryPerformanceCounter(ref long x);
    [DllImport("kernel32.dll")]
    extern static short QueryPerformanceFrequency(ref long x);
    private long m_endTime;
    private long m_startTime;
    private long m_frequency;

    public Form1()
    {
        InitializeComponent();
    }
    public void Begin()
    {
        QueryPerformanceCounter(ref m_startTime);
    }
    public void End()
    {
        QueryPerformanceCounter(ref m_endTime);
    }

    private void button1_Click(object sender, EventArgs e)
    {
        QueryPerformanceFrequency(ref m_frequency);
        Begin();
        for (long i = 0; i < 1000; i++) ;
        End();
        MessageBox.Show((m_endTime - m_startTime).ToString());
    }

Si vous êtes un C/C++, dev, alors jetez un oeil ici:
http://support.microsoft.com/kb/815668

Puisque nous sommes tous venus ici pour rapide des extraits plutôt ennuyeux explications, je vais en écrire un:

FILETIME t;
GetSystemTimeAsFileTime(&t); //unusable as is

ULARGE_INTEGER i;
i.LowPart = t.dwLowDateTime;
i.HighPart = t.dwHighDateTime;

int64_t ticks_since_1601 = i.QuadPart; //now usable
int64_t us_since_1601   = (i.QuadPart * 1e-1);
int64_t ms_since_1601   = (i.QuadPart * 1e-4);
int64_t sec_since_1601  = (i.QuadPart * 1e-7);

//unix epoch
int64_t unix_us  = (i.QuadPart * 1e-1) - 11644473600LL * 1000000;
int64_t unix_ms  = (i.QuadPart * 1e-4) - 11644473600LL * 1000;
double  unix_sec = (i.QuadPart * 1e-7) - 11644473600LL;

//i.QuadPart is # of 100ns ticks since 1601-01-01T00:00:00Z
//difference to Unix Epoch is 11644473600 seconds (attention to units!)

Aucune idée de comment la dérive de la performance-contre-réponses est allé jusqu'à, ne pas faire de glissement de bugs, les gars.