Производительность для Timer против DispatcherTimer - PullRequest
9 голосов
/ 04 декабря 2011

У меня нет конкретного сценария, но этот вопрос просто приходил мне в голову, когда я думал о сценариях, в которых я мог бы использовать Timer вместо DispatcherTimer.

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

  1. используйте обычный таймер, а затем используйте диспетчер приложения для изменить пользовательский интерфейс
  2. использовать DispatcherTimer (и, возможно, сделать мой вычислительный интенсивная работа в асинхронном фоновом режиме, если это необходимо).

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

EDIT:

У меня такое ощущение, что мой вопрос недостаточно ясен, поэтому я попытаюсь добавить конкретный, хотя и выдуманный пример.

Допустим, я должен читать большой файл каждые 2 минуты, а когда я закончу, я должен добавить элемент в ListBox. Допустим, чтение / обработка файла занимает 10-15 секунд, в течение которых у меня не работает пользовательский интерфейс. Что было бы лучшим подходом для чего-то подобного?

Ответы [ 6 ]

5 голосов
/ 04 декабря 2011

Основная точка:

для выполнения сложной вычислительной задачи

Это будет означать не с использованием DispatcherTimer.Он в основном существует для выполнения небольших задач в главном потоке и предотвращения создания другого потока.

Если вы используете DispatcherTimer для запуска Backgroundworker, вы обходите его основное назначение.

Так что просто используйте обычный таймер здесь.

2 голосов
/ 12 февраля 2012

После дополнительных исследований и анализа я пришел к выводу, что обычный таймер работает лучше всего в моем выдуманном примере. До сих пор мне не приходилось искать что-то конкретное, что могло бы вызвать потенциальные проблемы в моем коде. Сказав это, хорошие практики кодирования никогда не повредят!

1 голос
/ 09 января 2013

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

1 голос
/ 04 декабря 2011
  • Таймер генерирует повторяющиеся события в приложении

  • DispatcherTimer - это таймер, который интегрируется в очередь Dispatcher и обрабатывается в указанный интервал времени и взаданный приоритет.

Таймеры не гарантированно выполняются точно при наступлении временного интервала, но гарантированно не выполняются до наступления временного интервала.Это связано с тем, что операции DispatcherTimer помещаются в очередь Dispatcher, как и другие операции.Когда выполняется операция DispatcherTimer, она зависит от других заданий в очереди и их приоритетов.

Если в WPF application используется таймер, стоит отметить, что Timer runs on a different thread then the user interface (UI) thread.Чтобы получить доступ к объектам в потоке пользовательского интерфейса (UI), необходимо опубликовать операцию в диспетчере потока пользовательского интерфейса (UI) с помощью Invoke или BeginInvoke.Причины использования DispatcherTimer в отличие от Timer заключаются в том, что DispatcherTimer работает в том же потоке, что и Dispatcher, и можно установить DispatcherPriority.

0 голосов
/ 04 декабря 2011

Другой вариант - использовать DispatcherTimer для создания экземпляра класса BackgroundWorker на каждой итерации таймера. Это также освобождает вас от использования Dispatcher.Invoke / BeginInvoke во многих случаях.

0 голосов
/ 04 декабря 2011

Если вы хотите изменить скалярное (не коллекционное) значение, привязанное к элементу пользовательского интерфейса, вы можете сделать это не только из потока пользовательского интерфейса (например, из делегата таймера).И в этом случае вам не нужно использовать Dispatcher.Invoke / BeginInvoke.

...