Какой самый быстрый способ обновить пользовательский интерфейс WPF из потока без пользовательского интерфейса с большим объемом сообщений?

Question

Теперь у меня есть API в реальном времени, который получает кучу сообщений из сети и передает их в класс менеджера pubsub. время от времени может быть до 1000 мсг / с или более. Есть два разных потока, каждый из которых подключен к своему пабу sub. подписчики WPF windows. менеджер хранит список окон и их DispatcherSynchornisationContext.

Поток вызывает менеджер через интерфейсный метод.

Менеджер публикует через почту:

        foreach (var sub in Subscribers[subName])
        {
            sub.Context.Post(sub.WpfWindow.MyDelegate, data);
        }

это можно оптимизировать.

P.S. Пожалуйста, не спрашивайте, почему я думаю, что это медленно и все .. У меня нет ограничений. Любое решение бесконечно медленно. Я должен сделать все возможное, чтобы сделать это как можно быстрее . Прошу помощи в оценке - можно ли это сделать быстрее? Спасибо.

РЕДАКТИРОВАТЬ: найдено это: http://msdn.microsoft.com/en-us/library/aa969767.aspx

Answer 1

Аргумент с очередью остается.Что я делаю - это помещаю вещи в очередь, очередь запускает задачу, которая затем запускается в потоке обмена сообщениями и извлекает X элементов данных (1000 или их сколько).Единственное, что меня убило, это постоянное обращение к одному элементу (что происходит медленно), но выполнение этого пакета хорошо работает.Я могу поддерживать почти нулевую загрузку процессора на очень загруженном потоке данных ES в безумные времена и время.

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

Примечание: используйте подсказки WPF для включения кэширования gpu отображаемых растровых изображений.

В дополнение:

• Запускать каждое окно в своем собственном потоке / насосе сообщений
• ТЯЖЕЛО использовать асинхронные очереди.Издатель никогда не должен блокировать, каждое окно имеет свою собственную целевую очередь, которая является асинхронной.

Вы хотите, чтобы обработка была максимально отделена.Жестоко отделен.

Answer 2

Вот мое предложение для вас:

Я бы использовал ConcurrentQueue (поставляется с пространством имен System.Collections.Concurrent;). Фоновые работники подают свои сообщения в эту очередь. Поток пользовательского интерфейса берет таймер и вытягивает (скажем, каждые 500 мсек) кучу сообщений из этой очереди и показывает их пользователю. Другой возможный способ состоит в том, что поток пользовательского интерфейса будет делать это только по требованию пользователя. ConcurrentQueue предназначен для использования из разных потоков и одновременно (как следует из названия ;-))