Всем привет. Есть экселька (уже сохранена в xlsb) Весит при этом 56 метров и работать отказывается, естетсвенно. Пример с 1 строкой во вложении. По факту количество строк порядка 40 000 Кол-во столбцов +- как в примере. (бывает на 20 больше примерно) + 13 подключений PQ с большим количеством строк - все это на вкладках внутри файла. Вопрос: что сделать, чтобы это заработало?)
Sanja написал: Я бы отказался от почти 6 млн! формул
ну не совсем так.
например столбцы C-H поиск одного и тогоже и вывод из разных столбцов. Я обычно жертвую одним доаолнительным в котором ичщу строку а в нужных столбцах вывожу значение из нужного строка из найденной строки если не ошибка. аналогично по подобным Далее Сумма - если уже не нашли A4 зачем мучать сто раз сумму и не важно что она выдала 0. Но тут надо больше смотреть на то чего больше, присутствия по условию или отсутствия.
В любом случае, нужно смотреть реальные данные и оптимизировать. Хотя количество формул и правда большое.
Согласен, жестко с количеством формул . количеством строк и столбцов. но при таком пуле SKU - реально не понимаю как сделать иначе. В другой организации был куб и когда все формулы были вида cubvlaue все работало на ура. И подобный файл весил около 15 метров. вопоос остается открытым - как быть? (
Ну как вариант - не собирать всё это в этом файле, а собирать модель из источников этого добра. Из этого файла оставить список материалов, дат, и требуемых показателей. И вообще отказаться от Экселя, есть ведь другие инструменты для таких задач. Например Qlik тянет практически всё что угодно.
написал: Сергей Лисицын , Да практически все должны работать с UsedRange , но проверено что COUNTIFS берет все что скормили. Но все это опытным путем.
а если там ссылка на умную таблицу? разве так не на range работает? vlookup и xlookup тоже по идее только на range.
Цитата
написал: Вам сразу написалиЦитатаВ любом случае, нужно смотреть реальные данные и оптимизировать.
нууу... ввиду политик конфиденциальности, я не могу шарить реальные данные. самостоятельно макросы, конечно же, не изучу быстро.
насколько может помочь удаление полностью из книги запросов PQ и тянуть данные лукапами и суммпроизв (вместо суммесли) из отдельно лежащего файла? а, и чем заменить суммеслимн, чтобы работало на закрытом файле? суммесли через суммпроивз, а МН - непонятно
написал: ну тут мы бессильны . либо надо сомтреть что и как ( на реальных или измененных данных) или только догадыватся где собака зарыта.
Попробую уточнить насколько критично предоставить старые данные, но, чтобы табличка была релевантна. думаю только к концу недели будет инфа. тему пока не закрывайте, плз
БМВ написал: Представленные функции работают с используемой(занятой данными) областью.
Вот как раз и не все))) Ко мне на работе периодически подходят с вопросом, подобным вопросу автора темы. И очень часто помогает (или, по крайней мере, значительно уменьшает тормоза) замена ВПР(ххх;А:С;3;0) на ВПР(ххх;А$1:С$99999;3;0), где 99999 - минимальное число, заведомо большее количества строк, необходимых для поиска в ВПР. То же касается и ПОИСКПОЗ. Если таких ВПР немного, ну, до 100 штук, то более-менее нормально все, а вот если количество в тысячах, то так делать точно не нужно
_Boroda_, Саша, надо уже конкретно сравнивать на разных сборках, но мои и не только мои замеры показывали что эффект от лишнего досих пор присутсвует именно у COUNTIFS .
вот смотри это время 10000 расчетов =VLOOKUP("123",A:A,1,) 460,9375 =VLOOKUP(123,A:A,1,) 437,5 =VLOOKUP("123",A1:A100,1,) 457,0313 =VLOOKUP(123,A1:A100,1,) 410,1563
для точности еще раз и в другой последовательности =VLOOKUP(123,A1:A100,1,) 464,8438 =VLOOKUP("123",A1:A100,1,) 574,2188 =VLOOKUP(123,A:A,1,) 523,4375 =VLOOKUP("123",A:A,1,) 511,7188
123 находится в строке 8 остальной диапазон просто пуст.
на всякий случай на виртуалке не сильно накрученной в фоне крутится куча процессов, по этому разброс будет всегда, но не так он заметен.
А ты возьми реальную большую таблицу, столбцов в 30 и строк тысяч на 50. И вторую такую же. В первой пересортируй столбец А и в столбце К выводи ВПР-ом значение из столбца L второй таблицы. У тебя получится 50 000 ВПР. И вот это уже замерь
разницы в том ,указан или не указан ограниченный диапазон практически нет.
для верности
=VLOOKUP("300",A:B,2,) 10300,78 =VLOOKUP(300,A:B,2,) 10683,59 =VLOOKUP("300",A1:B40000,2,) 10210,94 =VLOOKUP(300,A1:B40000,2,) 10808,59 300 расположено в единственном числе и в сааамом конце строка 29960.
Значит, влияет наполненность таблицы, ее величина, возможные внутренние ссылки на вычисленные ВПР-ом значения, еще что-нибудь. Но вот я тебе говорю - как только ко мне приходят с вопросом про тормоза файла, который по идее тормозить не сильно должен, первое, что я делаю - смотрю, чтобы в ВПР не было диапазона на весь столбец. Исправляю и почти всегда помогает. Если не помогает, то в файле еще что-нибудь сидит, типа 100 000 стилей, скрытых имен или автофигур нулевого размера (встречались такие файлы, да)))
Даже если я сделаю везде диапазон, а не весь столбец, крайне маловероятно, что это поможет. 40к строк... тем более данные меняются. Во всех запросах PQ (ну в 80%) кол-во строк может быть меньше или больше.
ну то есть у вас основная проблема в SUMIFS, которых безумно много. Посмотреть бы еще на данные 'C:\Users\yasukki\Desktop\[Freestock.xlsb]Zopen
точнее, если данные хоть как то сгруппированы там, то возможно диапазоны нужно делать динамическими, предварительно один раз просчитав их для каждого дня, но что-то подсказывает что нужно сперва сделать сводную а потом выбирать от туда значения сумм по условиям и координате столбца например.
Ну, кстати, возможно еще проблема в том, что я к уже готовой после запроса PQ табличке добавляю различные расчеты. т.е. уже в умной таблице. пример добавил. Сам файо Zopen - до колонки H, а потом вычисления