Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1
RSS
Функция или запрос в PQ и скорость обновления: где лучше разместить больше шагов?
 
Всем привет.
Если собирать N файлов запросом PQ в один массив данных, как лучше поступать:
- максимум шагов добавлять в функцию и применять "большую" функцию к каждому файлу в головном запросе или
- делать функцию с минимумом шагов и добавлять все необходимые шаги в головном запросе после применения "маленькой" функции?
Есть ли тут какой-то универсальный совет?

Спасибо
 
Цитата
tabularasa написал:
или в разных обстоятельствах по-разному
ответа на Ваш вопрос не знаю.
попробуйте сделать несколько пробных файлов по миллиону строк данных. и сделайте два запроса: один со всеми шагами обработки в пользовательской функции и второй запрос с пользовательской функцией только для объединения файлов и последующей обработкой объединенных данных после работы пользовательской функции объединения. и сравните время выполнения запросов .
как сделать миллион строк данных посмотрите, например, здесь
 
tabularasa, лично я по максимуму стараюсь обработку производить до сборки. ИМХО так быстрее. Над общим массивом делаю только то что нельзя по-отдельности, скажем если из разных файлов могут придти дубли, то зачистку уже только после сборки.
Все вышеописанное основано на моем субъективном восприятии, специальных замеров производительности я не делал. Может где-то в буржуйском сегменте сети и найдёте подобное исследование. В рунете такого не видел.
Вот горшок пустой, он предмет простой...
 
Универсального ответа не знаю (не задумывался сильно о нем раньше).
Суть в том, что если вы сделаете минимум преобразований в функции, потом объедините и потом еще куча, то PQ придется работать с большой таблицей. И он будет пытаться запихнуть ее в память. Если данных очень много, то он будет таблицу "резать" и проводить преобразования по частям.
Если вы сделаете максимум преобразований в функции, то потом конечно ему будет легче, но всё равно получится, что он по частям делает. Плюс, поскольку источник - файлы, то есть чтение с диска, вы скорее не заметите большой разницы - всё равно все файлы ему придется прочесть с диска, и может быть неоднократно.

Но зависит также от типа операций - например, наверное лучше одно слияние, чем 10 слияний, и так далее.
F1 творит чудеса
 
вот такой еще вопросы. во время выполнения запроса на области справа появляются числа о загрузке 5..50..250 мб. у меня до 250 доходило, хотя размер файла меньше пяти мб. что это за цифры? и что в это время грузится? опер. память? процессор? и есть ли критический максимум? например, не более, скажем, тридцати процентов от ОЗУ
 
artyrH, это объем загружаемых данных из источников данных. Если у вас источники скажем 50мб, но вы обращаетесь к ним 5 раз, то PQ будет грузить 250мб. Вроде должны были добавить кэш, но добавили или нет - не в курсе
Изменено: Dark1589 - 17 Апр 2019 13:31:46
 
Dark1589, так бывают цифры больше чем сам объём источника
В жизни нет ничего невозможного! Есть только недостаток знаний и умений.
 
Александр, отредактировал сообщение) PQ не кэширует исходник, а постоянно его загружает при обращении. Думаю Максим или Пух смогут более развёрнуто ответить


Вот тут Андрей писал о тестировании кэша в PQ
Изменено: Dark1589 - 17 Апр 2019 13:38:01
 
Dark1589, надеюсь, критического максимума нет
 
artyrH, посмотрите тут . Описан объем 1 и 4гб
 
Dark1589, спасибо
 
Большое спасибо всем. Познавательно.

У меня вообще файлы на сервере лежат и к ним обращение по сети идет. Я чего-то не думал, что обращений к одному и тому же файлу может быть >1. Вообще собираю 1,5 млн строк из ~100 файлов разного размера и все встает колом. Пару месяцев назад данных было чуть меньше и все работало. Уж не знаю, что изменилось, обновления ли офиса, критическая масса достигнута или политики безопасности стали мешать.
Кину на локальный ssd, мож попустит, а то устал смотреть в диспетчере задач на подвисшие процессы mashup и эксель с пометкой "оч высокое энергопотребление"
 
Dark1589, кэш добавили, но только в версии Эксель 2019 и, как я понимаю, в О365 тоже должно быть. Работает уже с ноября 2018.
tabularasa, если столько обращений, то нужно оптимизировать запрос. Чтобы понимать как оптимизировать нужно понимать какой(ие) из шагов генерят такие обращения и с ними по-колдовать. Колдовать можно по-разному. Можно в нужные места Table.Buffer по-навтыкать, можно то же преобразование другой функцией реализовать (те что реализуются кнопочным методом далеко не всегда оптимальны).
Изменено: PooHkrd - 18 Апр 2019 01:04:40
Вот горшок пустой, он предмет простой...
 
PooHkrd, сейчас приходится работать на 10-13, так что 19 только в мечтах) А есть данные по скорости обработки с кэшем и без?
 
Я режу лишнее заранее, чтобы потом не иметь дело с супер большими таблицами. Отсекайте по чуть-чуть, чтобы потом не утонуть в таблице информации. Оно и логично, если не задумываться.
Если задуматься, то, от перестановки слагаемых сумма не меняется. Не знаю, применимо ли это правило в наших случаях.

В общем, отсеивайте заранее.

Хорошего дня! =)
Улыбнись.
 
Цитата
Dark1589 написал:
19 только в мечтах)
а мечтать зачем.. взяли бы да установили
 
artyrH, ну дома мне 16 вполне хватает, а на работе вариантов нет. У всех 10-13 + Win7. Апгрейд до 19 и Win10 будет супер дорогим
 
Цитата
Dark1589 написал:
будет супер дорогим
да, вообще то, раз есть деньги платить..
 
Товарищи, а у вас часто наблюдается такая картина?
В запросе функция которая таблицу преобразуется в 3 столбца "индекс", "атрибут" и "значение", функция применяется к двум файлам. Затем в атрибуте правятся заголовки, чтобы развернуть потом в одинаковый, ну и разворачивается. Короче даже не суть что делается, достаточно часто наблюдаю такую картину со 100% загрузкой проца и "высоким энергопотреблением" процессов excel & mashup..
Скрытый текст
Страницы: 1
Читают тему (гостей: 1)
Наверх