Как лучше реализовать обновление состояний объектов?

[Fregloin]

Постараюсь объяснить доступно и кратко.
Есть клиент и сервер. Формат общения тесктовый json (пока). Есть объект, у которого есть различные свойства (определены через Q_PROPERTY). Сервер передает клиенту состояния этих объектов (объектов много, их несколько разных типов). Под состоянием я понимаю набор текущих значений этих свойств. После получения json парсится, далее я прохожу по разобранному json, на основании полученных id объектов нахожу их, и дальше найденному объекту скармливаю json узел, который содержит дагнные о его свойствах. На основании полученного состояния происходит отрисовка элемента на сцене должным образом. Но что то мне подсказывает, что такой механизм далек от идеала. Вот и думаю, как сделать по уму, что бы данные с серва парсились в отдельном потоке, а отрисовка была в осном потоке + синхронизация по потокам была толковая.
Сейчас как, иду по json дереву, нашёл id объекта, достал его из хеша, и передаю этот узел парситься внутрь объекта (виртуальная функция). Объект узнает, изменилось ли состояние или нет (на основании сравнения с предыдущим), если изменился - то дает соотвествующий сигнал. В другом объекте на этот сигнал заведен слот, и при его вызове опррашиваются свойства (Q_PROPERTY) этого объекта и задаются нужные цвета и атрибуты связанному элементу сцены. Т.е. по сути парсинг и отрисовка идет в реальном времени. На небольших количествах объектов это работает достаточно быстро. Но вот будет объект, на котором будет задействовано 8 мониторов1920*1080, и на них будет запущена одна программа, которая будет рисовать довольно много графики на сцене. Закрадываются сомнения по поводу того, как будет работать текущая модель.
Как мысль, завести два массива объектов-состояний, один в котором будут парситься после приема данных, а во второй будут копироваться первые после изменений.
Вобщем я пока запутался.

[Bepec]

Ну во 1 протестить на количестве объектов. (хотя если Graphics View должно потянуть, хотя хз. У меня сток мониторов нет)

Во 2 отказаться от текстового формата в бинарный формат.  Это снизит нагрузку на сеть и операции с бинарным форматом быстрее в разы. И парсить каждый раз строки - это пипец Сам недавно так лопушнулся с оптоволокном. Со строками тормозило, с бинарным полетело.

В 3 подумать о модели, продумать архитектуру. Возможно вам ничего и не стоит менять. А мб стоит всё переделать

PS а тестировать то есть на чём?

[Fregloin]

Текст понимаю что гемор, но есть 2 других программиста, которые пишут серваки для моих клиентов, и пока они особо не жаждут переходить на бинарный протокол. при том, уже был печальный опыт, когда не было никакой расширяемости протокола. есть реализация binaryJSON, процентов на 30-40 иногда больше объем данных получается меньше ну и парсинг быстрее.
но опять же, те программисты говорят, вот для отладки давай будем в тексте передавать, так и осталось. и это при условии, что данные идут пакетами (в несколько десятков а то и сотен кб) до 4 раз в секунду...

[Bepec]

Я тоже могу рассказать столько интересных историй
Аля высоконагруженное приложение, работающее по трём гигабитным интерфейсам, пищущее о каждом принятом и отправленном пакете в текстовый файл Объём лога превыщает объем данных через первые пять секунд запуска  до печального конца свободного места на жёстком диске через 10 минут. И каждые 10 минут его перезапускал ватчер

Сейчас решать вам. Я бы предложил просто - взять целевой комп и запустить там тестовую версию программы. И посмотреть - ляжет или нет.
А потом выяснить почему лёг. А потом посмотреть справляется ли он с данными

PS в общем тут больше посоветовать не могу, ибо нужно знать объёмы, мощности, цели наконец ^.^

[Fregloin]

Постараюсь нарисовать толковую слоксхему потоков данных в программе и краткую ее структуру на днях. может действительно оставить все как етсь.