Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 След.
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
так может имеет смысл где-то в этом направлении пошуршать?
Тут вроде уже и нет ничего, что помогло бы решить данную конкретную задачу. Разве что принудительно отключать фоновое выполнение и возвращать обратно, но это, как уже писал выше, оставил на крайний случай.

Цитата
Дмитрий(The_Prist) Щербаков написал:
.. разделить RefreshAll и проверку запросов... это просто финт такой.
Про такой финт уже тоже подумал, приходится в некоторых случаях использовать, да, но не помогло: те запросы, которые успели обновиться к моменту запуска процедуры проверки, показывают в refreshing значение False, а те, которые не успели, так и зависают в True, пока на них в отладчике не остановишься  :cry:  

P.S.
И я не понял, зачем убирать отключение\возврат пересчета, обновления экрана и т.д. в процедуре проверки, там же основная тягомуть с изменениями происходит?
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
Для начала я бы рекомендовал назвать переменную не refreshing, а хотя бы IsRefreshing - чтобы не дублировать имя свойства.
Да, мой косяк, но в данном случае ни на что не повлиял, уже проверял.

Цитата
Дмитрий(The_Prist) Щербаков написал:
Убрать любые обработчики ошибок.
Да, не помогло.

Цитата
Дмитрий(The_Prist) Щербаков написал:
глюк проявляется на всех запросах или на одном конкретном.
Еще не проверял. Хитрость в том, что они все друг на друга завязаны, но вручную все обновляется, как надо. Тут поэкспериментирую еще.
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
Интерес к теме стремительно теряется: обсуждается всю тему один код с одними объектами, а Вы совершенно иной объект используете.
Не понял наезда..)
Я ориентировался по названию темы. Которое, как и ее содержание, полностью совпадает с озвученной мной проблемой. Как раз подумал, что плодить темы нехорошо, поэтому и задал вопрос здесь.
Цитата


Дмитрий(The_Prist) Щербаков написал:
Вот это убрать не пробовали: wb.Model.Refresh? Зачем обновлять модель принудительно, когда она при необходимости будет обновлена через RefreshAll?
Были причины так делать, но это неважно, потому что обновление модели после цикла запускается. Важно то, что выполнение из цикла не выходит, пока в режиме отладки не остановиться на refreshing = qt.refreshing и не продолжить, после чего все работает как надо. То есть проблема как будто бы в том, что фоновый процесс не завершается, пока выполнение не остановится в отладчике. Мне кажется, что с чем-то похожим уже сталкивался, но склероз, маразм и старческое слабоумие не дают сосредоточиться и вспомнить) Поэтому надеюсь на более здоровых и опытных)

Цитата
Дмитрий(The_Prist) Щербаков написал:
Файл прикладывайте
Я сам всегда так говорю: присылайте файл, разберемся, и "времени на все эти вытягивания информации жаль", но за выкладывание этого файла  расстреляют на месте без суда и следствия) Плюс данные обновляются из внешних источников, поэтому от одного файла толку будет мало. И я почти уверен, что это какая-то общая проблема, связанная с выполнением кода параллельно асинхронному процессу. Но ничего не нарыл пока. Можно, конечно, попробовать отключать фоновый режим и потом возвращать обратно, но пока надеюсь найти другие способы обхода.
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
ну вот его и надо выкладывать, а не какой-то его отдельный кусок.
Да, надо было сразу выложить, торопился.

Цитата
Дмитрий(The_Prist) Щербаков написал:
qt - явно объект WorkbookConnection.
Нет, это QueryTable:
Код
Private Sub UpdateAllData_WaitPQ()
Dim wb As Workbook
Dim qt As QueryTable
Dim ws As Worksheet
Dim lo As ListObject
Dim pt As PivotTable
Dim refreshing As Boolean
Dim calcMode As XlCalculation
Dim toolong As Boolean
Dim t As Date

    Set wb = ThisWorkbook
    Application.ScreenUpdating = False
    calcMode = Application.Calculation
    Application.Calculation = xlCalculationManual
    Application.DisplayAlerts = False
    t = Now
    
    On Error GoTo fin
    
    wb.RefreshAll
    
    Do
        If Now - t > TimeSerial(0, 0, 30) Then
            If MsgBox("Для обновления необходимо еще какое-то время. Продолжить?", vbQuestion + vbYesNo) = vbNo Then
                toolong = True
            Else
                t = Now
            End If
        End If
        
        refreshing = False
        
        For Each ws In wb.Worksheets
            For Each lo In ws.ListObjects
                Set qt = getLoQueryTable(lo)
                If Not qt Is Nothing Then
                    refreshing = qt.refreshing
                    Debug.Print qt.Connection & " " & refreshing
                    If refreshing Then Exit For
                End If
                DoEvents
            Next lo
            If refreshing Then Exit For
        Next ws
        
    Loop Until Not refreshing Or toolong
    
    If refreshing Then Err.Raise vbObjectError + 513, , "Обновление не завершено!"
    If Not wb.Model Is Nothing Then
        wb.Model.Refresh
    End If
    
    For Each ws In wb.Worksheets
        For Each pt In ws.PivotTables
            pt.PivotCache.Refresh
            pt.RefreshTable
        Next pt
    Next ws
    
    MsgBox "Обновление завершено!", vbInformation
    
fin:
    Application.Calculation = calcMode
    Application.ScreenUpdating = True
    Application.DisplayAlerts = True
    
    If Err.Number <> 0 Then MsgBox "Внимание: " & Err.Description, vbCritical
    
End Sub

Private Function getLoQueryTable(lo As ListObject) As QueryTable
On Error Resume Next
    Set getLoQueryTable = lo.QueryTable
On Error GoTo 0
End Function


Руками обновляется меньше минуты. При запуске UpdateAllData_WaitPQ оно будет крутиться до бесконечности (с подтверждением продолжения), но если во время выполнения ткнуть точку останова на refreshing = qt.refreshing и продолжить, то все обновляется и завершается, как надо.
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Дмитрий(The_Prist) Щербаков, сорри, код другой и проблема в том, что когда эта штука гоняется в цикле:

Код
  
...
If Not qt Is Nothing Then
    DoEvents
    refreshing = qt.refreshing
    Debug.Print qt.Connection & " " & refreshing
End If
...


debug выводит True до бесконечности, но стоит в процессе выполнения поставить точку останова на refreshing = qt.refreshing, debug сразу выводит False. То есть как будто бы только при остановке выполнения свойство refreshing обновляется. Либо только при остановке обновление действительно завершается.
Изменено: dhead - 18.02.2026 12:58:35
Может ли запуск PQ-скриптов из VBA увеличить их время выполнения против обычного запуска?, Теоретический вопрос
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
Возможно из-за того, что обновляются ВСЕ запросы по очереди.

Столкнулся с похожей проблемой и не догоняю: почему в RefreshAllAndWait обновляются запросы по очереди? Там же в самом начале RefreshAll , а потом просто в цикле у каждого соединения проверяется свойство Refreshing. Проверяю аналогичным образом и получаю бесконечный (или очень долгий) цикл, то есть Refreshing (если выводить через Debug.print) всегда True. Но стоит через какое-то время поставить точку останова на строке с проверкой, как Refreshing сразу становится False. Ну то есть в режиме отладки проверка работает, а в рантайме - нет  8-0
Изменено: dhead - 18.02.2026 11:48:22
метод "align" для объекта "button" в схеме ribbon xml
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
Но есть вот это:
Спасибо, что напомнили про версию 2 (MS-CUSTOMUI2) !
Я по привычке из соображений совместимости все свойства из первой смотрю)
метод "align" для объекта "button" в схеме ribbon xml
 
Цитата
Sanja написал:
Я для вертикального выравнивания использую пустые <labelControl>
Тоже подумал про пустые labelControl, но у них же вроде как высоту не поменять? То есть можно двинуть только на целый размер контрола. То есть один относительно трех, например. А тут их 2..
метод "align" для объекта "button" в схеме ribbon xml
 
Цитата
grigju написал:
параметр Top сдвигается ниже чем у соседних из группы по 3
Интересно, как это получается. У меня такие кнопки располагаются по сетке, без центрирования по вертикали. Вообще, странное желание, на мой взгляд:) Такое центрирование делает вид ленты более неряшливым, что ли..

Цитата
grigju написал:
Объект Box с параметром Вертикальный не работает
Не работает - то есть не раскидывает кнопки по вертикали, или не центрирует?
метод "align" для объекта "button" в схеме ribbon xml
 
grigju, не совсем понял, что значит "с централизацией по середине в вертикале":)
Вероятно, имеется в виду группа кнопок в ленте, которые должны быть расположены не по горизонтали (слева направо), а по вертикали (сверху вниз).
Похоже, это то, что нужно.
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Update.

Поторопился написать, что проблема решилась с помощью записи\чтения formulaLocal и formula временной ячейки. Да, все работает, но есть нюанс.

Подразумевается, что адреса в формулах ссылаются на листы в активной на момент вычисления книги. То есть записываются в формате 'Имя листа'!A1 без имени книги, так как заранее оно неизвестно. И тут появляется одна особенность: если на момент записи формулы в ячейку открыта книга (именно книга) с именем Имя листа, либо даже книга, в котором есть связь с книгой с именем Имя листа, то ссылка автоматом преобразуется так, что имя листа в адресе превращается в имя книги, а вместо имени листа подставляется имя первого листа из этой книги. Звучит запутанно, вот пример:

Есть открытая книга Книга.xls, в которой мы пишем в ячейку формулу. В книге нет никаких связей.
Есть книга С:\Тест\тест.xlsx с листом Лист1, которая закрыта.
Есть открытая книга Другая книга.xls, в которой есть линк на С:\Тест\тест.xlsx

Вставляем любую формулу на любом листе в любую ячейку книги Книга.xls. В формуле есть ссылка на лист тест. Например, =ЛЕВСИМВ('тест'!A1;5). И при вставке эта формула автоматом преобразуется в...  =ЛЕВСИМВ('[С:\Тест\тест.xlsx]Лист1'!A1). То есть при вставке формулы эксель судорожно начинает искать лист с именем тест в текущей и во всех открытых книгах, не находит, но зато в одной из соседних книг находит линк на книгу (не лист) с таким именем, меняет ссылку, да еще и внаглую меняет имя листа с тест на Лист1.

Никакие манипуляции с настройками не дают возможности отключить такой творческий подход. И как это вылечить, не очень понятно.

Пока все, что приходит в голову, это несколько расширить синтаксис и для страховки от подобных совпадений писать все ссылки на листы в таком формате: '[.]тест'!A1. Подразумевая под [.] активную на момент вычисления книгу. Эксель считает это ссылкой на конкретную книгу и в таком случае уже не пытается подсунуть что-то другое.
Ну а перед передачей строки в Evaluate просто удалять из нее все [.].

Или все-таки есть другие варианты обхода?
Изменено: dhead - 24.01.2026 04:42:34
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
ну т.е. ничего Вы не поняли. Ок. Попробуем разжевать.

Ну вот, обвинения начались: ничего не понял и фантазии нет:))

Еще раз: я в курсе, что RefersToLocal работает с багом, сам давал ссылку на справку от майкрософт и писал, что все было бы ок с именами, если бы оно работало без багов. Поэтому согласен, что конвертировать с помощью имен с таким багом - плохая затея, это я уже понял и уже искал тут альтернативу именам и записью\чтению ячеек, о чем писал выше.

По поводу фантазии: поверьте, ее дофига, как только не извращался и чего только не делал с Excel, начиная с версии 97 года, не меньше вашего, наверное. Некоторые извращения доводил до коробочного варианта и продавал за большие доллары (с аппаратными ключами для защиты, чтобы копировать неповадно было:) Каких только внутренних багов не отлавливал, когда еще интернетов не было. То есть интернет-то был уже, только нужной инфы в нем было мало. Иногда приходишь к тому, что проще отдельную прогу написать, а Excel дергать только по мере необходимости, либо вообще забыть:)

Цитата
Дмитрий(The_Prist) Щербаков написал:
Копии книги и листов лишь пара вариантов. Можно это делать и в отдельных пустых ячейках и даже(!) в уже заполненных

Да, можно, но это чревато потерей или повреждением данных после экселевсих сбоев, остатками мусора, который потом придется чистить, как ни ухищряйся, потому что все контролировать не получится, слишком много ограничений. Тем более, что файлы чужие.

Ну или я действительно до чего-то не догадался, так поделитесь, буду благодарен.

Возможно, я перфекционист и слишком перестраховываюсь, даже скорее всего, иногда самого себя по рукам бить приходится, ведь не софт для марсианского корабля строишь.

Короче,
в текущей задаче проблема решилась простой манипуляцией с ячейками, т.к. все работает из надстройки и собственные листы можно использовать как заблагорассудится.

Но вопрос все же остается: возможно, кто-то знает или придумает третий вариант, без записи в ячейки и без имен.
Изменено: dhead - 20.01.2026 13:43:19
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
nilske, как сказать:) Полноценная книга со всей иерархией объектов ради одной ячейки. Разве что в воздухе. Но есть риск, что рухнет, если что-то пойдет не так:)
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Цитата
Дмитрий(The_Prist) Щербаков написал:
то чем плохо использование отдельного скрытого листа для таких целей? Чем он хуже создания имени с кучей нюансов?

Во первых, плохо чисто идеологически. Это как заказывать служебный автобус для того, чтобы сгонять за батоном в магазин, находящийся в твоем же доме на первом этаже:)  Да, пользователь не заметит разницы, но .. короче, вы поняли:)

Ну и в случае каких-то сбоев, которые при активном использовании Excel происходят довольно часто, допускать ошмётки в виде лишних листов в документах (путь даже очень-очень скрытых:) - плохой стиль. Невидимый документ, повисший в памяти - тоже некрасиво:) Да, я всегда использую обработку ошибок (что при сбоях поможет не всегда), плюс при следующем запуске можно будет все автоматом почистить, но это как-то неряшливо, что ли.

Лишнее скрытое уникальное имя смущает гораздо меньше. Ограничение на длину строки в данном конкретном случае не помешает, не будет там таких формул. И, если бы все работало, как оно должно работать, это было бы простое и надежное решение.

Цитата
Дмитрий(The_Prist) Щербаков написал:
.. а разделитель пробовали менять? Я об этом в первом своем сообщении намек делал - видимо, он не достиг цели

Разумеется, пробовал, я же тоже давал ссылку на описание бага от самих майкрософт:)

Цитата
Дмитрий(The_Prist) Щербаков написал:
сможете корректно определить именно разделители аргументов для каждой произвольной функции/формулы, взятой из ячейки? А точно уверены, что у всех пользователей именно тот разделитель, который Вы считаете разделителем?

Во первых, разделитель в системе пользователя определить не проблема - это xlListSeparator, как пишут в справке. Во-вторых, его и не нужно было бы определять: пользователь на своем компе вводит формулу в соответствии со своими региональными настройками, мы ее конвертим из RefersToLocal в RefersTo (если бы оно работало как заявлено, без багов) и сохраняем. У любого другого пользователя с его региональными настройками конвертим обратно и выводим в поле на понятном ему языке. При этом сохраненная формула в нативном синтаксисе всегда правильно вычисляется с помощью Evaluate.

Все точно так же будет работать с ячейками на временном листе, но, как я уже сказал, мне не нравится автобус:) Поэтому и задавал вопрос. В надежде, что кто-нибудь находил какое-нибудь третье простое решение.
Изменено: dhead - 20.01.2026 02:03:32
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Цитата
Sanja написал:
Вы уверены, что этот язык человеческий и привычный?

Для русскоязычного и в меру продвинутого Excel-пользователя язык формул с местной локализацией – привычный и человеческий по сравнению с буржуинским оригиналом, как это ни странно:)

Цитата
Дмитрий(The_Prist) Щербаков написал:
Если честно - плохо понимаю вообще смысл этого действия. Здесь ошибок может быть куча: начиная от разделителей и заканчивая грамматикой.

Достаточно того, что юзер умеет писать без ошибок локализованные формулы. Парсить текст и делать валидацию необязательно. Ошибется в локализованном синтаксисе - получит шиш на выходе, проверит и исправит. А с нативным придется напрягаться подольше с непривычки:)

Смысл действия попытался объяснить выше: есть прога, имеющая кучу настроек, которые динамически выводятся в виде полей в UserForm. Поле может быть текстбоксом, комбобоксом и т.д. В текстбоксах может храниться не только обычное текстовое значение, но и ссылка на ячейку или диапазон, например, а кроме того - формулы.

То есть поле может быть вычисляемым.
Все это нормально работает, но только в том варианте, который может прожевать Evaluate. А хотелось бы облегчить юзерам жизнь и дать им возможность вписывать в поля формулы так, как они привыкли (на русском языке, с разделителем ";")

По идее, если формула написана без ошибок в локальном варианте, создание имени с преобразованием из RefersToLocal в RefersTo (что давно предлагал ZVI)  должно прекрасно работать. Но почему-то не получается. А гадить в чужой лист временными ячейками с производственным мусором как-то некрасиво. Создавать\удалять или держать ради этого отдельный лист – тоже.
Изменено: dhead - 19.01.2026 14:39:06
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Неужели ни у кого такой проблемы не возникало? Пока решения не нашел, а хотелось бы..
Макросом записать в ячейку формулу, возвращающую написание формулы из другой ячейки и ее расчетное значение.
 
Что-то этот трюк не работает у меня.

Задача такая: в интерфейсе с настройками (msForms) дать пользователю возможность задать параметр с использованием привычных ему формул Excel на "человеческом" языке. К примеру, в поле Параметр1 пользователь может написать СУММ(Лист1!A1;Лист1!A2), а программа должна преобразовать это в нативный формат и вычислить с помощью Evaluate.

Использовать для этого временную ячейку на листе кажется не очень правильным, а с именами какая-то странность: то ошибка 1004 при добавлении имени, то имя добавляется, но RefersTo отдает то же самое, что хранит RefersToLocal, хотя при этом преобразование из A1 в R1C1 работает.

Кажется, при добавлении любой экселевской формулы в RefersToLocal эксель считает, что вся строка с формулой неправильная.

Поиск по форуму и гуглам открывает некоторые нюансы:

Microsoft сообщает о проблемах с RefersToLocal
Пользователи пишут, что иногда приходится пошаманить со свойством Comment

Все перепробовал, не помогает. Файл с примером во вложении.

P.S.
Офис 2021, версия Excel 2108, 64-разрядная
Изменено: dhead - 28.12.2025 21:08:23
Совместимость .XLSB в разных версиях Excel?
 
Alexcx, пару раз сталкивался с тем, что xlsb вдруг переставал открываться, но подробностей не помню.
А с другими своими файлами этот же трюк повторить не пробовали? Чтобы понять, насколько стабильный эффект)
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Цитата
irabel написал:
А прямое копирование разве проходит мимо буфера обмена?
До ваших результатов считал, что да.. Какой смысл задействовать буфер обмена, если известен пункт назначения? Это как если бы Васе нужно было переложить пачку денег из правой руки в левую, но он задействовал бы для этого еще Петю) Да и Майкрософт говорит про необязательный параметр Destination метода Copy вот что:
Цитата
Specifies the new range to which the specified range will be copied. If this argument is omitted, Microsoft Excel copies the range to the Clipboard.
Что, конечно, можно интерпретировать по-разному, но как-бы намекает, что если destination не указан, то копирует в буфер, а если указан, то просто создает в нужном месте копию. И это косвенно подтверждает ваш антивирус тоже.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
irabel, во-первых, там нет ничего такого, а во-вторых – вы результаты-то видели? через буфер обмена получается в десятки раз быстрее, чем при прямом копировании. Поэтому и антивирусы не на первом месте среди подозреваемых. Да и временно отключить я их сам не смогу, надо сначала гипотезу с версиями Excel опровергнуть.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Проверил на 2007.

test1: 0.16
test2: 0,31
test3: 0,30
test4: 0,01

То есть так, как оно по идее должно быть, и как у sokol92 на 2016.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Цитата
sokol92 написал:
Я думаю, что попытка за 0,66 сек 100 раз обновить буфер обмена является непростой задачей для MS Windows
Тем не менее у меня на разных машинах оно работает гораздо быстрее, чем прямое копирование. Это и странно. И сильно сомневаюсь, что это как-то может повлиять на стабильность. Следующая после Copy операция не начнет выполняться, пока не завершится копирование, а копирование не завершится, пока винда не скажет, что оно завершилось)
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Цитата
nilske написал:
А какая может быть закономерность для разных машин, с разным объёмом свободной памяти, и набором программ, в частности, разными антивирусами )

Закономерность такая, что по идее (и как пишет sokol92, ) на любом компе и на любой версии excel первый метод должен работать быстрее, чем второй и третий. Плюс по идее драматической разницы между ними быть не должно. Но пока что на разных компах 2019 и 2021 ведут себя с точностью до наоборот. Если у кого-то под такими же версиями будет работать так, как ожидается (особенно интересно посмотреть на 2019 32-разрядную), то гипотезу о зависимости от версий Excel можно будет отбросить, а она пока основная.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
sokol92, так я бы тоже оставался при таких же рекомендациях, если бы не увидел то, что вижу на 19 и 21 версиях Excel:) На разных машинах. Кстати, и диапазоны копируются точно так же. Rows(n).Copy Rows(m) проворачивается от двух до двадцати раз медленнее, чем Rows(n).Copy: Rows(m).PasteSpecial. У вас нет возможности проверить на других версиях? Вечером попробую на 2007.

Цитата
sokol92 написал:
P.S. У Вас макрос находится в модуле листа (а не стандартном модуле), так что не запускайте его кнопкой.
Намеренно находится там для чистоты эксперимента, потому что в конкретной задаче он может находиться только там. Кстати, а кнопка чем помешает?

Цитата
sokol92 написал:
P.P.S. После команды PasteSpecial, если буфер обмена больше не нужен, лучше добавить строку:К
Это просто тест, в реальном коде все на месте.

В общем, граждане! У кого есть возможность прогнать на своих компах, не проходите мимо. Любопытно же. Может хоть какая-то закономерность определится.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
sokol92, такое впечатление, что вы вообще не вникали в то, что я писал выше и в результаты выложенного примера тоже.

Цитата
sokol92 написал:
Общее замечание - следует минимизировать число взаимодействий между VBA и Excel
Я знаю, как оптимизировать обработку данных, сводя к минимуму взаимодействие с ячейками напрямую (обработать таблицу с миллионом строк и парой сотен столбцов за секунды – не проблема). Но как вы сформируете любую итоговую таблицу с нужный форматом КАЖДОЙ отдельной ячейки в ней, не взаимодействуя с Excel?

Цитата
sokol92 написал:
100 раз копируют информацию ... Копирование диапазона ячеек во много раз быстрее
100 – это как раз приблизительное число ячеек итогов в конкретной задаче, которые необходимо отформатировать в соответствии с данными и форматами ячеек на других листах. Думаете, я с диапазонами работать не умею?)

Цитата
sokol92 написал:
Методы 2-3 100 раз копируют информацию в буфер обмена и вставляют информацию из буфера обмена. В эффективных программах необходимо минимизировать количество таких операций.
Вы не заметили, что результаты теста противоречат вашим рекомендациям (и моим ожиданиям, кстати, тоже)? Внезапно через буфер обмена получается раз в 10 быстрее))

Короче, вопрос остается: в чем прикол? Почему на практически одинаковых машинах с плюс-минус одинаковыми процессорами, одинаковым объемом оперативы и соседними версиями Excel время выполнения операции копирования ячеек может отличаться в десятки раз? И как это можно обойти?
Пока что нашлось одно странное решение: вопреки интуиции, здравому смыслу и рекомендациям sokol92,  копировать через copy-pastespecial (на одних машинах получается быстрее раза в два, на других – в десять).

Может быть все-таки есть другие способы?
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
sokol92
Во вложении простой пример.
Отличия по времени выполнения соответственно примерно в 20, в 4, в 3 и в 5 раз.
Способы 2 и 3 периодически меняются местами по скорости, но общее соотношение сохраняется. Особенно впечатляет отличия для самого очевидного (казалось бы) и короткого по коду способа копирования. Вместо этого, оказывается, гораздо быстрее получается перенести сначала значение, а потом скопировать формат.
Изменено: dhead - 23.04.2025 12:01:42
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Пример выложить не могу, к сожалению. Но я описал все предельно точно. Именно операция копирования ячейки в ячейку (обе находятся на одном листе) и присвоение ячейки числового формата (cells(r,c).numberformat = str) на одном файле с одними и теми же данными на одних компах выполняется в десятки раз медленнее, чем на других. А в какой-нибудь день может пролететь за доли секунды, но потом опять тупит. А на других компах всегда работает быстро.

И это тестовый файл, в котором ничего не меняется. Но сталкивался с этим и на других файлах тоже, в основном именно при копировании ячейки в ячейку. Завтра поэкспериментирую на чистых файлах с чистым кодом, может быть прояснится что-нибудь.
VBA. Медленная работа cells.copy и cells.format, На некоторых компьютерах.
 
Периодически напарываюсь на такое, но универсального решения не нашел.
Может кто-то уже сталкивался и нашел причины и методы обхода.

Проблема: один и тот же файл с одним и тем же кодом на одних компах обрабатывается быстро (1-2 секунды), на других -- медленно (30-40 секунд). Тормоза начинаются на копировании одной(!) ячейки в другую (cells(r1,c1).copy cells(r2,c2)) и на присвоении формата одной ячейке или диапазону из нескольких ячеек. На каждую такую операцию уходит в десятки раз больше времени на условно "медленных" компах, чем на "быстрых".

Разумеется, все большие данные обрабатываются в массивах, работа непосредственно с ячейками нужна только для формирования таблицы с отчетом.

ScreenUpdating, Calculation и все такое прочее установлены правильно, да и на данном конкретном коде не сильно влияют на скорость (размер таблицы небольшой).

Загадочности добавляет тот факт, что иногда и на "медленных" компах оно вдруг начинает проворачиваться быстро, но потом снова тупит. Есть незначительные отличия в железе, плюс на некоторых компах под 64-разрядной windows установлен 32-разрядный Excel. Есть подозрение, что именно на 32-разрядных Excel 2019 происходит такой тупняк, но статистику еще не собрал.
Совместное редактирование файлов Excel, Поиск вариантов одновременной работы в Exel модели без shared desk
 
Jul_25, приложение писал на VBA, принцип работы похож на тот, что описан Михаилом выше: у каждого пользователя свой excel файл, синхронизация данных осуществляется через промежуточные xml файлы, которые находятся в сетевой папке. Есть главный пользователь, который создает таблицу, других пользователей и группы, настраивает поля, которые доступны для редактирования и т.д. Каждая строка имеет свой id и набор статусов с информацией об изменениях. Также предусмотрен механизм защиты целостности данных при работе с копиями файлов пользователей и много чего еще.
Но прежде чем все это начинать делать, стоит хорошенько подумать над другими способами реализации вашей задачи)
Изменено: dhead - 10.04.2025 10:54:01
Избавиться от появления фоновых процессов Excel
 
asesja, я понимаю, что причин может быть много. В описанных случаях несколько из них явно присутствуют (вылеты при работе с макросами на тяжелых и кривых файлах, или при работе с sap, например), но они малоустранимы: таких файлов и макросов дофига и далеко не все из них даже можно поправить, так как они могут поступать извне.  

Мой вопрос, скорее, подразумевал гипотетическое существование решения, которое позволит игнорировать зависший в фоне процесс так, чтобы новый экземпляр запускался в полноценном режиме со всеми подключенными ранее надстройками (а они отключаются разом все). Кстати пришла сейчас в голову мысль: проверить запуск с ключом /x с подвисшим в фоне процессом. Может сработает. Но тоже костыль, конечно. Даже если как-то извратиться с запуском в таком режиме по двойному клику, то несколько тяжелых файлов наверняка будут отжирать памяти заметно больше.
Страницы: 1 2 3 4 5 След.
Наверх