Почему моя программа на C # работает быстрее в профилировщике?

Luaan опубликовал решение в комментариях выше, это общесистемное разрешение таймера. Разрешение по умолчанию составляет 15,6 мс, профилировщик устанавливает разрешение 1 мс.

У меня была точно такая же проблема, очень медленное выполнение, которое ускорялось при открытии профилировщика. Проблема исчезла на моем компьютере, но снова появилась на других компьютерах, казалось бы, случайным образом. Мы также заметили, что проблема исчезла при запуске окна «Присоединиться ко мне» в Chrome.

Мое приложение передает файл по шине CAN. Приложение загружает сообщение CAN с восемью байтами данных, передает его и ожидает подтверждения. С таймером, установленным на 15,6 мс, каждый проход туда и обратно занимал ровно 15,6 мс, а вся передача файла занимала около 14 минут. Если таймер установлен на 1 мс, время приема-передачи будет изменяться, но будет всего 4 мс, а общее время передачи упадет до менее двух минут.

Вы можете проверить разрешение системного таймера, а также узнать, какая программа увеличила разрешение, открыв командную строку от имени администратора и введя:

powercfg -energy duration 5

Где-то в выходном файле будет следующее:

Разрешение таймера платформы: разрешение таймера платформы По умолчанию разрешение таймера платформы составляет 15,6 мс (15625000 нс), и его следует использовать всякий раз, когда система находится в режиме ожидания. Если разрешение таймера увеличивается, технологии управления питанием процессора могут оказаться неэффективными. Разрешение таймера может быть увеличено за счет воспроизведения мультимедиа или графической анимации. Текущее разрешение таймера (единицы 100 нс) 10000 Максимальный период таймера (единицы 100 нс) 156001

Мое текущее разрешение составляет 1 мс (10 000 единиц по 100 нс), за ним следует список программ, которые запросили повышенное разрешение.

Эту информацию, а также более подробную информацию можно найти здесь: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

Вот код для увеличения разрешения таймера (изначально опубликованный как ответ на этот вопрос: как установить разрешение таймера с C # на 1 мс?):

public static class WinApi
{
    /// <summary>TimeBeginPeriod(). See the Windows API documentation for details.</summary>

    [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Interoperability", "CA1401:PInvokesShouldNotBeVisible"), System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Security", "CA2118:ReviewSuppressUnmanagedCodeSecurityUsage"), SuppressUnmanagedCodeSecurity]
    [DllImport("winmm.dll", EntryPoint = "timeBeginPeriod", SetLastError = true)]

    public static extern uint TimeBeginPeriod(uint uMilliseconds);

    /// <summary>TimeEndPeriod(). See the Windows API documentation for details.</summary>

    [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Interoperability", "CA1401:PInvokesShouldNotBeVisible"), System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Security", "CA2118:ReviewSuppressUnmanagedCodeSecurityUsage"), SuppressUnmanagedCodeSecurity]
    [DllImport("winmm.dll", EntryPoint = "timeEndPeriod", SetLastError = true)]

    public static extern uint TimeEndPeriod(uint uMilliseconds);
}

Используйте это так, чтобы увеличить разрешение: WinApi.TimeBeginPeriod(1);

И вот так, чтобы вернуться к значениям по умолчанию: WinApi.TimeEndPeriod(1);

Параметр, переданный в TimeEndPeriod (), должен совпадать с параметром, переданным в TimeBeginPeriod ().

Бывают ситуации, когда замедление потока может значительно ускорить другие потоки, обычно когда один поток часто опрашивает или блокирует какой-то общий ресурс.

Например (это пример оконных форм), когда основной поток проверяет общий прогресс в жестком цикле вместо использования таймера, например:

private void SomeWork() {
  // start the worker thread here
  while(!PollDone()) {
    progressBar1.Value = PollProgress();
    Application.DoEvents(); // keep the GUI responisive
  }
}

Замедление может улучшить производительность:

private void SomeWork() {
  // start the worker thread here
  while(!PollDone()) {
    progressBar1.Value = PollProgress();
    System.Threading.Thread.Sleep(300); // give the polled thread some time to work instead of responding to your poll
    Application.DoEvents(); // keep the GUI responisive
  }
}

Делая это правильно, следует вообще избегать использования вызова DoEvents:

private Timer tim = new Timer(){ Interval=300 };

private void SomeWork() {
  // start the worker thread here
  tim.Tick += tim_Tick;
  tim.Start();
}

private void  tim_Tick(object sender, EventArgs e){
  tim.Enabled = false; // prevent timer messages from piling up
  if(PollDone()){
    tim.Tick -= tim_Tick;
    return;
  }
  progressBar1.Value = PollProgress();
  tim.Enabled = true;
}

Вызов Application.DoEvents() может потенциально вызвать выделение головной боли, когда элементы графического интерфейса не были отключены, и пользователь запускает другие события или одно и то же событие во второй раз одновременно, вызывая подъем стека, который по своей природе ставит в очередь первое действие после нового, но я ухожу не по теме.

Возможно, этот пример слишком специфичен для winforms, я попробую сделать более общий пример. Если у вас есть поток, который заполняет буфер, который обрабатывается другими потоками, не забудьте оставить некоторый System.Threading.Thread.Sleep() резерв в цикле, чтобы позволить другим потокам выполнить некоторую обработку, прежде чем проверять, нужно ли снова заполнять буфер:

public class WorkItem { 
  // populate with something usefull
}

public static object WorkItemsSyncRoot = new object();
public static Queue<WorkItem> workitems = new Queue<WorkItem>();

public void FillBuffer() {
  while(!done) {
    lock(WorkItemsSyncRoot) {
      if(workitems.Count < 30) {
        workitems.Enqueue(new WorkItem(/* load a file or something */ ));
      }
    }
  }
}

Рабочий поток будет иметь трудности с получением чего-либо из очереди, поскольку он постоянно блокируется потоком заполнения. Добавление Sleep () (вне блокировки) может значительно ускорить другие потоки:

public void FillBuffer() {
  while(!done) {
    lock(WorkItemsSyncRoot) {
      if(workitems.Count < 30) {
        workitems.Enqueue(new WorkItem(/* load a file or something */ ));
      }
    }
    System.Threading.Thread.Sleep(50);
  }
}

В некоторых случаях подключение профилировщика может иметь тот же эффект, что и функция сна.

Я не уверен, привел ли я репрезентативные примеры (довольно сложно придумать что-то простое), но я думаю, что суть ясна: размещение sleep () в правильном месте может помочь улучшить поток других потоков.

---------- Редактировать после Update7 -------------

Я бы вообще удалил эту LoopDataRefresh() ветку. Лучше поместите таймер в свое окно с интервалом не менее 20 (что было бы 50 кадров в секунду, если бы ни один не был пропущен):

private void tim_Tick(object sender, EventArgs e) {
  tim.Enabled = false; // skip frames that come while we're still drawing
  if(IsDisposed) {
    tim.Tick -= tim_Tick;
    return;
  }

  // Your code follows, I've tried to optimize it here and there, but no guarantee that it compiles or works, not tested at all

  if(signalNewFFT && PanelFFT.Visible) {
    signalNewFFT = false;

    #region FFT
    bool newRange = false;
    if(graphFFT.MaxY != d.fftRangeYMax) {
      graphFFT.MaxY = d.fftRangeYMax;
      newRange = true;
    }
    if(graphFFT.MinY != d.fftRangeYMin) {
      graphFFT.MinY = d.fftRangeYMin;
      newRange = true;
    }

    int tempLength = 0;
    short[] tempData;

    int i = 0;

    lock(d.fftDataLock) {
      tempLength = d.fftLength;
      tempData = (short[])d.fftData.Clone();
    }

    graphFFT.SetLine("FFT", tempData);

    if(newRange) graphFFT.RefreshGraphComplete();
    else if(PanelFFT.Visible) graphFFT.RefreshGraph();
    #endregion

    // End of your code

    tim.Enabled = true; // Drawing is done, allow new frames to come in.
  }
}

Вот оптимизированная функция SetLine (), которая теперь принимает не список точек, а необработанные данные:

public class GraphFFT {
    public void SetLine(String lineTitle, short[] values) {
      IPointListEdit ip = zgcGraph.GraphPane.CurveList[lineTitle].Points as IPointListEdit;
      int tmp = Math.Min(ip.Count, values.Length);
      int i = 0;
      peakX = values.Length;

      while(i < tmp) {
        if(values[i] > peakY) peakY = values[i];
        ip[i].X = i;
        ip[i].Y = values[i];
        i++;
      }
      while(ip.Count < values.Count) {
        if(values[i] > peakY) peakY = values[i];
        ip.Add(i, values[i]);
        i++;
      }
      while(values.Count > ip.Count) {
        ip.RemoveAt(ip.Count - 1);
      }
    }
  }

Надеюсь, у вас это сработает, как я уже говорил, у меня не было возможности скомпилировать или проверить это, чтобы там могли быть какие-то ошибки. Там есть еще кое-что, что нужно оптимизировать, но оптимизация должна быть незначительной по сравнению с усилением пропуска кадров и сбором данных только тогда, когда у нас есть время на самом деле нарисовать кадр до того, как появится следующий.

Если вы внимательно изучите графики в видео на iZotope, то заметите, что они тоже пропускают кадры и иногда немного нервничают. Это совсем не плохо, это компромисс между вычислительной мощностью потока переднего плана и фоновых рабочих.

Если вы действительно хотите, чтобы рисование выполнялось в отдельном потоке, вам придется нарисовать график в растровое изображение (вызов Draw () и передача контекста устройства растровых изображений). Затем передайте растровое изображение в основной поток и обновите его. Таким образом, вы потеряете удобство конструктора и сетки свойств в своей среде IDE, но сможете использовать свободные ядра процессора.

---------- редактировать ответ на примечания --------

Да, есть способ узнать, что вызывает. Посмотрите на свой первый снимок экрана, вы выбрали граф «дерево вызовов». Каждая следующая строка немного перескакивает (это древовидная структура, а не просто список!). В графе вызовов каждый узел дерева представляет метод, который был вызван его родительским узлом дерева (методом).

На первом изображении WndProc был вызван около 1800 раз, он обработал 872 сообщения, из которых 62 инициировали ZedGraphControl.OnPaint() (что, в свою очередь, составляет 53% от общего времени основных потоков).

Причина, по которой вы не видите другого корневого узла, заключается в том, что в третьем раскрывающемся списке выбрано «[604] Mian Thread», чего я раньше не замечал.

Что касается более плавных графиков, у меня есть 2 мысли по этому поводу, после более внимательного просмотра снимков экрана. Основной поток явно получил больше (двойных) сообщений об обновлении, и у ЦП все еще есть запас.

Похоже, что потоки рассинхронизированы и синхронизированы в разное время, когда сообщения об обновлении приходят слишком поздно (когда WndProc был завершен и некоторое время засыпал), а затем внезапно на какое-то время вовремя. Я не очень знаком с Ants, но есть ли у него параллельная шкала времени потока, включая время сна? Вы должны увидеть, что происходит в таком ракурсе. Появится инструмент просмотра потоков от Microsoft. пригодится для этого:

Когда я никогда не слышал и не видел ничего подобного; Я бы порекомендовал здравый смысл комментировать разделы кода / вводить возвраты на вершину функций, пока вы не найдете логику, вызывающую побочный эффект. Вы знаете свой код и, вероятно, имеете обоснованное предположение, с чего начать. В противном случае рубите в основном все в качестве теста на работоспособность и начинайте добавлять блоки обратно. Меня часто удивляет, как быстро можно найти эти, казалось бы, невозможные ошибки. Как только вы найдете соответствующий код, у вас будет больше подсказок для решения вашей проблемы.

Существует множество возможных причин. Не заявляя о полноте, вот как вы могли бы подойти к поиску истинной причины:

• Переменные среды: проблема с таймером в другом ответе - это только один пример. Могут быть изменения Пути и других переменных, профилировщик может установить новые переменные. Запишите текущие переменные среды в файл и сравните обе конфигурации. Попробуйте найти подозрительные записи, отключите их одну за другой (или в комбинации), пока не получите одинаковое поведение в обоих случаях.

• Частота процессора. Это легко может произойти на ноутбуках. Потенциально система энергосбережения устанавливает более низкую частоту процессора (ов) для экономии энергии. Некоторые приложения могут «разбудить» систему, увеличивая частоту. Проверьте это через монитор производительности (permon).

• Если приложения работают медленнее, чем это возможно, должно быть какое-то неэффективное использование ресурсов. Используйте профилировщик, чтобы исследовать это! Вы можете прикрепить профилировщик к (медленному) запущенному процессу, чтобы увидеть, какие ресурсы используются недостаточно / чрезмерно. В основном есть две основные категории причин слишком медленного выполнения: выполнение с привязкой к памяти и выполнение с привязкой к вычислению. Оба могут дать больше информации о том, что вызывает замедление.

Однако если ваше приложение на самом деле изменяет свою эффективность, присоединяясь к профилировщику, вы все равно можете использовать свое любимое приложение для мониторинга, чтобы увидеть, какие показатели производительности действительно меняются. Опять же, perfmon - ваш друг.

Если у вас есть метод, который генерирует множество исключений, он может работать медленно в режиме отладки и быстро в режиме профилирования ЦП.

Подробно здесь, производительность отладки можно повысить с помощью атрибута DebuggerNonUserCode. Например:

[DebuggerNonUserCode]
public static bool IsArchive(string filename)
{
    bool result = false;
    try
    {
        //this calls an external library, which throws an exception if the file is not an archive
        result = ExternalLibrary.IsArchive(filename);
    }
    catch
    {

    }
    return result;
}