Add(StringTableMT,4905930,532,140)
{
Left=170
Top=5
Width=780
Height=240
Font=[Open Sans,10,0,0,204]
Columns=#1:0|1:1|1:2|1:3|1:4|1:5|1:6|1:7|1:8|1:9|2:10|2:11|2:12|2:13|2:14|2:15|2:16|2:17|2:18|2:19|2:20|2:21|2:22|2:23|2:24|2:25|2:26|2:27|2:28|2:29|2:30|2:31|2:32|2:33|2:34|2:35|2:36|2:37|
ColumnClick=1
MinColWidth=20
MaxColWidth=120
Redaction=0
IconsCheck=[]
MiscIcons=[]
Icons=[]
FileName="online"
SaveColProp=0
SaveWidth=0
Point(Matrix)
Point(Strings)
Point(doReplace)
Point(onDblClick)
Point(doAutoColWidth)
Point(doSave)
}
Add(IndexToChanel,11721130,427,154)
{
Point(Index)
link(onEvent2,4905930:doReplace,[])
}
Этот топик читают: Гость
Ответов: 704
Рейтинг: 7
|
|||
|
Приветствую! Столкнулся с тем, что таблица строк на 7 строк по 38 колонок каждая ощутимо тормозит главный поток при полной перерисовке через замену строк. И если горизонтальной прокруткой поработать активно, то главный поток совсем вешается на этот период. Так и нужно? Просто каждые 3 секунды данные в таблице полностью обновляются и к таблице имеют доступ через матрицу строк или массив строк другие участки схемы - важно чтоб она функционировала без тормозов. Это слишком большая нагрузка? Компонент для этого не предназначен?
|
|||
| карма: 0 |
|
Ответов: 8921
Рейтинг: 823
|
|||
|
Neo, компьютер-то глуповат (не то, что мы, программисты), даёшь команду заменить одну строку, а он начинает перерисовывать все десять тысяч
  |
|||
| карма: 19 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): Компонент для этого не предназначен? А че схема какая-то куцая, таблица и IndexToChanel в довесок, остальное -- догадайся сам? А данные где, где движуха этих данных, как я могу увидеть тормоза таблицы, если она лысая? А может это не таблица тормозит, а весь остальной кусок схемы, когда системе надо перерисовать таблицу, а схема мочалит данные? Попробуй сгенерировать свою ошибку из десятка компонентов по схожему алгоритму, тогда и глянем, что там конкретно тормозит. К тому же, я бы крайне не рекомендовал этот тип таблицы, лучше всего использовать MTStrTbl. Она и более функциональна, и более оптимизирована для работы с MT. --- Добавлено в 2019-01-03 23:09:07 Леонид писал(а): даёшь команду заменить одну строку, а он начинает перерисовывать все десять тысячТак оно и есть, но 10000 это ты хватанул, конечно. А вот всю видимую область -- так это кашей не корми, на любой чих. Редактировалось 3 раз(а), последний 2019-01-03 23:09:07 |
|||
| карма: 22 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
nesco писал(а): А может это не таблица тормозит, а весь остальной кусок схемы, когда системе надо перерисовать таблицу, а схема мочалит данные?Так и оказалось, смоделировал отдельно кусок таблицы. Спасибо за подсказку. Схема большая, где-то кто-то таки мочалит. |
|||
| карма: 0 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
Всех с наступающим праздником!
Оказалось не в данных дело. Смоделировал схему отдельно. При прокрутке таблицы (захватить и медленно тащить) явно тормозит отсчет событий текстовом поле. Так же все процессы на системном потоке откладываются. Я что-то неправильно применяю? Критические секции поставил для развязки потоков таймера от визуальных элементов. |
|||
| карма: 0 |
|
|
Ответов: 8921
Рейтинг: 823
|
|||
|
Neo, таскай / не таскай -- везде 10 событий/сек
 НичегоНеТормозит.jpg |
|||
| карма: 19 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): Смоделировал схему отдельноА почему не так? СхемаНафига этот MMTimer нужен? И нафига там вообще SafeMode? Вообще-то работу потоков и надо делать в режиме: асинхронный -- сохраняем данные, синхронный -- даем команду на вывод сохраненных данных. |
|||
| карма: 22 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
MMTimer как главный таймер для многих операций в моей программке по обработке данных контроллера. Он ведет внутреннее время и показано как оно уходит на "обработка данных" в параллельном потоке. А вывод на форму сделан через сейфмод чтоб избежать ошибки приложения (их таки есть у меня).
nesco, по Вашему примеру объясните, пожалуйста, разве не будет одновременного доступа к данным Memory на запись и на чтение если вдруг отрисовка подвиснет и произойдет следующее событие записи при чтении еще старого по onSyncExec? И разве параллельный поток не теряет свое преимущество параллельности в случае такого частого данных на форму по точке onSyncExec? Он ведь дожидается их обработки визуальными элементами? Таймер у меня читал новое значение реже, чем их отсчитывал MMTimer именно чтоб меньше перерисовывать визуальные элементы. --- Добавлено в 2019-01-06 22:02:40 Леонид, у меня с предложенной Вами схемой при таскании 8-12 в секунду, и 10 если форму не трогать. Редактировалось 1 раз(а), последний 2019-01-06 22:02:40 |
|||
| карма: 0 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): по Вашему примеру объясните, пожалуйста, разве не будет одновременного доступа к данным Memory на запись и на чтение если вдруг отрисовка подвиснет и произойдет следующее событие записи при чтении еще старого по onSyncExec? И разве параллельный поток не теряет свое преимущество параллельности в случае такого частого данных на форму по точке onSyncExec?onSyncExec всегда работает в главном потоке, те параллельный поток выставляет флаг на выдачу сообщения и указатель на метод обработки этого события в обработчике главного потока внутренним методом Sender.Synchronize(SyncExec), а сам продолжает выполняться дальше. И ему совершенно безразлично, дойдет это сообщение до главного потока или не дойдет, те параллельный поток не ждет окончания события главного потока. Вот какое сообщение дойдет до главного потока, те текущие данные и будут прочитаны из Memory. И вообще надо исходить из того, что полного распараллеливания априори быть не может, тк все это поточное безобразие работает цепочкой в кольце обработчика ядра системы. А у параллельного потока стоит еще 100 мсек спать, те ни черта не делать, а за это время можно слона съесть. Редактировалось 4 раз(а), последний 2019-01-06 22:44:38 |
|||
| карма: 22 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
nesco писал(а): И вообще надо исходить из того, что полного распараллеливания априори быть не может, тк все это поточное безобразие работает цепочкой в кольце обработчика ядра системы.За то это позволяет не виснуть всей программе в случае работы с сетью, например. Спасибо за разъяснения. А все флаги обязательны к выполнению в главном потоке, или как и в DeferredEvent - кому повезет, тот и выполнится? И по поводу вот такого примера, данные уже синхронизированы с главным потоком после MT_String? |
|||
| карма: 0 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): И по поводу вот такого примера, данные уже синхронизированы с главным потоком после MT_String? Смотря в чем ты это читаешь? MT_String, в данном случае -- буфер, если используется событие onResult, то выдаваться оно будут в том потоке, в котором запущена вся цепь событий. Если же использовать нижнюю точку Result, то прочитать ее можно когда угодно, но будут ли данные актуальны, тут надо уже смотреть весь алгоритм. Neo писал(а): А все флаги обязательны к выполнению в главном потоке, или как и в DeferredEvent - кому повезет, тот и выполнится? DeferredEvent -- это такой же, только короткий оконный обработчик, как и главный. Те оба этих обработчика обрабатываются системой почти одинаково. Те, как система отработает очереди событий для обработчиков, так и будет, похерит она их или не похерит, это уже к ней вопросы. Это вполне может произойти при переполнении очереди событий. Тут все зависит еще и от того, как вызывается обработчик, если послано SendMessage, то вызывающая функция ждет окончания выполнения события, если же как у DeferredEvent -- послано PostMessage, то событие ставится в очередь на обработку, те откладывается, а события цепи выполняются дальше. Естественно, что SendMessage более приоритетен, чем PostMessage, тк невыполнение первого может привести к зависанию приложения, невыполнение же второго просто не приведет к дальнейшим действиям, но управление уже будут передано системе внутри приложения. Редактировалось 1 раз(а), последний 2019-01-06 23:19:37 |
|||
| карма: 22 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
nesco писал(а): И вообще надо исходить из того, что полного распараллеливания априори быть не может, тк все это поточное безобразие работает цепочкой в кольце обработчика ядра системы. А у параллельного потока стоит еще 100 мсек спать, те ни черта не делать, а за это время можно слона съесть.Это дает возможность не использовать мьютекс, читая значение по onSyncExec? События и onExec и onSyncExec отдаются системе на обработку с разным приоритетом и совместного доступа к данным быть не может? Кажется я избыточно пытаюсь использовать сейфмод в погоне за безотказностью приложения. |
|||
| карма: 0 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): События и onExec и onSyncExec отдаются системе на обработку с разным приоритетом и совместного доступа к данным быть не может? Тут есть один нюанс -- это использование нескольких потоков для накопления данных, вот тогда надо уже чесать репу, а когда же их читать, по какому onSyncExec, или использовать что-то другое, и не будут ли они лезть одновременно друг с другом к буферу данных на запись. Редактировалось 1 раз(а), последний 2019-01-07 00:17:51 |
|||
| карма: 22 |
|
|
Ответов: 704
Рейтинг: 7
|
|||
|
Спасибо, проясняется. Может есть под рукой любой рабочий проект с потоками и их синхронизацией, который можно посмотреть в качестве примера грамотного построения?
|
|||
| карма: 0 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
Neo писал(а): Может есть под рукой любой рабочий проект с потоками и их синхронизацией, который можно посмотреть в качестве примера грамотного построения?Вот тут http://forum.hiasm.com/topic/67198/2 (в конце) я вроде выкладывал что-то мультипоточное. Посмотри, может пригодится. Эта схема есть полностью мультипоточная, но я ее не выкладывал. Редактировалось 1 раз(а), последний 2019-01-07 01:24:30 |
|||
| карма: 22 |
|
Поиск
Друзья
Администрация