Проскакивала тут раньше тема про медленный скролл, если много столбцов и записей выведено на экран, ну и мой пост с вопросом о многопоточности.
Так вот:
- заметил, что, чем больше данных выведено на монитор, тем больше грузит ядро проца при прокрутке таблиц. Если сузить размер окна программы (по вертикали / горизонтали, не важно) - нагрузка на ядро уменьшается. Видимо что-то просчитывает и/или отрисовывает процом в каждой ячейке.
- у меня есть запрос на простой форме к таблице у которой и размеры полей уменьшены по самое "оно" и самих полей не так уж много, но в запросе есть раскраска ячеек+строк по условию и штук 10 вычисляемых текстовых/числовых столбцов. Так там форма по клику открывается довольно быстро, а вот при скролле запроса развернутого на весь экран моника 24", переход к следующей строчке запроса (при скролле) аж секунда-две и ядро ЦП загружено по полной. (при сжатом окне до размеров мобильника скроллит шустро и загрузка ядра ЦП 50-70%)
- и вот оно самое ИНТЕРЕСНОЕ: открыл базу локально с сервера и по РДП, где стиль серверной винды 2003 - классический, без красивостей теней итп, ну и плюс сам РДП всю графику не передает, и вот ТАМ ЦП практически не грузит при скролле того самого, большого запроса, и сам скролл довольно шустрый.
---- Так может тут дело как раз в прорисовке таблиц при обычном (красивом) стиле винды и отсюда все эти тормоза? и может даже автору моё наблюдение пригодится и он когда-нибудь это поправит)) эх... Хотя может тут вообще не в этом весь сыр.
Последняя версия DataExpress 3 beta от 31 января 2019 года. Скачать. Энциклопедия DX. Форум на develop-soft.
Наблюдение по производительности DX при прокрутке
Re: Наблюдение по производительности DX при прокрутке
Спасибо за наблюдение. У меня нет большого монитора, чтобы это проверить. Алгоритмы раскраски запроса и табличной части формы отличаются. К сожалению, алгоритм в запросе не оптимальный по некоторым причинам, поэтому возможны тормоза на высоких разрешениях.
Re: Наблюдение по производительности DX при прокрутке
А какие выражения в раскраске? Может есть "тяжелые"?
-
- Интересующийся
- Сообщения: 141
- Зарегистрирован: Вт мар 14, 2017 11:41 am
- Откуда: Гомель, Беларусь
Re: Наблюдение по производительности DX при прокрутке
Да обычные, но есть 2 ссылающихся на вычисляемые поля типа "Если результат вычисляемого поля=1, то зеленый"admin писал(а):А какие выражения в раскраске? Может есть "тяжелые"?
Тут дело в том, что в интерфейсе (хр-классическом) на Windows server 2003, то тоже и раскраска рисуется, и выводится на большой моник (только по РДП), и НЕ тормозит никак.
А на домашнем компе с SSD и i5-7500 + дискретная GTX-750ti грузит проц при прокрутке, и аж видно, как все эти множества ячеек пробегают по экрану будто каждая по очереди стирается из одной строчки и рисуется в другой.
--Сужаешь размер окна программы или в дизайнере делаешь размер окна запроса а-ля 640х480 и лаги почти проходят (проц грузит, но не 100%, а 50-70).
---Лагают при прокрутке не только запросы, представления "только таблица" - тоже самое (и даже без раскраски), но немного быстрее, чем тот большой запрос на простой форме.
-
- Интересующийся
- Сообщения: 141
- Зарегистрирован: Вт мар 14, 2017 11:41 am
- Откуда: Гомель, Беларусь
Re: Наблюдение по производительности DX при прокрутке
Пытался забить строки просто символами, ради теста.
- Сделал пустую базу с 1й таблицей и тестил.
- 1 текстовое поле шириной 150 символов, забиты все 150, строк около 120-ти. Влазит в моник около 70 строк.
== при прокрутке лагает.
- 2 текстовых поля шириной по 70 символов,
== лагает точно так
- Если сузить окно программы так, чтобы был виден 1 столбец из 2х - Лагает в 2 раза меньше.
- Если сузить по-вертикали, чтобы влазило в 2 раза меньше строк - Лагает в 2 раза меньше.
- Если один столбец со 150 символами визуально сужать/расширять - ничего особо не меняется. (видимо показ символов где-то рендерится, но их просто не все видишь в ширине столбца)
- Если покрасить как-то по условию - лагает чуть-чуть сильнее, практически неотличимо от некрашеного варианта.
- Если сделать вычисляемые поля, то чем "длиннее" результат, тем сильнее лагает при прокрутке.
+++ Из сетевой базы видно, что каждый раз докачиваются данные во время прокрутки.
=== Такое чувство, что при КАЖДОМ шаге прокрутки вся выводимая на экран область очищается в ноль и полностью повторно загружается в новые места в сетке таблицы (со смещением, но заново)! Вот если бы грид сам мог ездить вверх/вниз, а строки подтягивались из ОЗУ, заранее догружаемые при необходимости из базы.... честно говоря я без понятия, насколько это реализуемо в DX и стоит ли заморачиваться, просто делюсь наблюдением.
- Сделал пустую базу с 1й таблицей и тестил.
- 1 текстовое поле шириной 150 символов, забиты все 150, строк около 120-ти. Влазит в моник около 70 строк.
== при прокрутке лагает.
- 2 текстовых поля шириной по 70 символов,
== лагает точно так
- Если сузить окно программы так, чтобы был виден 1 столбец из 2х - Лагает в 2 раза меньше.
- Если сузить по-вертикали, чтобы влазило в 2 раза меньше строк - Лагает в 2 раза меньше.
- Если один столбец со 150 символами визуально сужать/расширять - ничего особо не меняется. (видимо показ символов где-то рендерится, но их просто не все видишь в ширине столбца)
- Если покрасить как-то по условию - лагает чуть-чуть сильнее, практически неотличимо от некрашеного варианта.
- Если сделать вычисляемые поля, то чем "длиннее" результат, тем сильнее лагает при прокрутке.
+++ Из сетевой базы видно, что каждый раз докачиваются данные во время прокрутки.
=== Такое чувство, что при КАЖДОМ шаге прокрутки вся выводимая на экран область очищается в ноль и полностью повторно загружается в новые места в сетке таблицы (со смещением, но заново)! Вот если бы грид сам мог ездить вверх/вниз, а строки подтягивались из ОЗУ, заранее догружаемые при необходимости из базы.... честно говоря я без понятия, насколько это реализуемо в DX и стоит ли заморачиваться, просто делюсь наблюдением.