Страницы: 1
RSS
Зачем сражаться за секунды выигрыша по скорости работы макроса?
 
Здравствуйте.
    Ни один раз тут видел темы, в которых ищут как выполнить необходимые действия кодом как можно быстрее. И сравнивая разные макросы в этих темах даже добиваются времени выполнения кода в пару секунд/пол секунды, и выбирают тот код, который справляется на пару милисекунд быстрее. Но почему так принципиальна такая скорость? Ведь визуально не заметно, выполняется код одну секунду или пять. Зачем же так биться за каждую милисекунду выигрыша во времени выполнения кода? Объясните, пожалуйста, если вас не затруднит.
Изменено: Счастливчик - 26.04.2024 14:00:09
 
Счастливчик, думаю, что эта тема больше для курилки подходит.
А по Вашему вопросу, могу сказать как пользователь, скорость работы макросов очень важна при больших очень больших объемах обрабатываемых данных, да и потом, несколько или много макросов могут работать последовательно, и если они все будут не "быстрые", но общее время их работы может существенно затянуться.
P.S. ну и доля спортивного интереса присутствует.
Изменено: Maximich - 26.04.2024 14:06:32
Кто ясно мыслит, тот ясно излагает.
 
Демонстрируется возможность оптимизации кода. Выражаясь простым языком, "применяя такой метод, мы на каждом шаге экономим 1 секунду, если таких шагов будет 1000, то сэкономим 20 минут."
 
1. Если что-то работает медленно - это не значить что оно потребляет мало ресурсов, скорее наоборот, потребляет много, а выполняется долго - береги планету, не грей воздух
2. Вот так один макрос отработал чуть медленнее. второй в сравнении с ним тоже едва заметно четь медленнее , а вместе за день накоплено куча времени ожидания - Копейка  рубль бережет
3. Если разовый макрос  - конечно не стоит вылизывать, если конечно сразу не удалось оптимально написать. Я часто, например для PowerShell, не код пишу с перебором, а в таблице готовлю набор однотипных команд с параметрами, одну отладил, остальные копипэстом запустил.  Но если это постоянно работающее, то просто недопустимо шлак в продуктив отправлять, хотя сейчас стало не модно код причесывать. Накидают абы как.
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал:
береги планету, не грей воздух
неоднозначно  :D

А вообще конечно, можно и нужно сражаться не столько за секунды, но и вот за такую КРАСОТУ
Изменено: nilske - 26.04.2024 20:25:52
 
nilske, красота ли?
По вопросам из тем форума, личку не читаю.
 
Цитата
nilske написал:
такую  КРАСОТУ
От Автора-оптимизатора: "Небольшая статистика того что получилось:
18 модулей против 1 у Васи
~380 строк кода (из них можно смело вычесть примерно 20 строк, т.к. это атрибуты Rubberduck) против ~100 у Васи".
Изменено: bedvit - 27.04.2024 08:41:27
«Бритва Оккама» или «Принцип Калашникова»?
 
Счастливчик,
в целом все просто:
1) Если задача разовая, то не стоит сильно заморачиваться по скорости (в разумных пределах). Такие задачи у меня сейчас часто появляются в связи с локализацией различных штук в компании
2) Если задача постоянная, то однозначно стоит бороться за скорость, но тоже нужно понимать, кто пишет код, т.к. трудозатраты могут быть не рациональными для этого.
 
Цитата
nilske: за такую  КРАСОТУ
про Conditional Compilation Arguments не знал, но, вроде, и не нужно это мне. Вообще, статья — полный скам и я бы такое никогда не посоветовал и, тем более, не назвал красотой.
     Улыбнулся, прочитав Это очень плохая практика – объявление всех переменных блоком в начале процедуры. Всегда лучше объявлять их непосредственно перед первым использованием.. Ну да, ну да  :D
Изменено: Jack Famous - 27.04.2024 10:02:42
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
Jack Famous, ну вот это пожалуй единственное утверждение, которое вызвало сомнения, но скорее остался непонятным из-за отсутствия аргументов.
буду рад если вы укажете аргументы против, потому что также не согласен  )
 
Что касается места объявления переменных.
Далее личное мнение, оценочное суждение итд итп. Никому не навязываю, просто рассказываю.

Есть подозрение, что это пришло из других языков, где просто нельзя написать по-другому. Но в VBA этого ограничения нет.
Изначально я объявлял переменные в начале процедуры/функции, так научили.
Потом заметил, что удобнее объявлять их перед первым использованием. Какие плюсы:
- Если процедура длинная(не надо так делать), то чтоб объявить переменную нужно пролистать вверх, написать текст, вернуться - пролистать вниз. Удобнее же просто написать текст без проматывания туда-сюда.
- Второй не менее значимый момент. Если вдруг процедура разрослась, и ты решил её отрефакторить, выделить логический кусок в отдельную процедуру. То вырезание куска кода происходит проще, если переменные находятся в этом же блоке.

Я пару раз отвечал на форуме, когда мне задавали вопросы, зачем я так делаю. Ответ был в духе "мы так делали, и будем делать, а твои аргументы ни о чём". Так что, эту точку зрения никому не навязываю, но и в удобстве обратного вы меня не убедите )
 
Цитата
МатросНаЗебре написал:
есть подозрение, что это пришло из других языков, где просто нельзя написать по-другому.
Да там похоже пытаются притянуть специфику разработки в какой-нибудь джаве, на vba. Объявление переменныв внутри цикла на vba не имеет смысла, поскольку не отражает реальный принцип работы и может только запутывать.
 
МатросНаЗебре, если называть переменные "yy" или "xxxxxx", то разницы совершенно нет )
но, как я полагаю, всё меняется если давать переменным осмысленные названия и перечислять их в самом начале с комментариями после каждой
и последующее чтение кода уже не будет приводить к результату "вдруг откуда ни возьмись"
 
Цитата
написал:
Объявление переменныв внутри цикла на vba не имеет смысла
Про это речи не было.
 
nilske, я писал про место объявления переменных. Имена переменных - это другая тема, не менее важная и интересная, но тем не менее, это про другое.
 
Цитата
МатросНаЗебре: в удобстве обратного вы меня не убедите
у меня аргумент один — удобно видеть все переменные в одном месте единым списком. Там их можно организовать по смыслу, убрать лишние, добавить новые.
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
Если объявлять переменные перед первым использованием, просто соблюдая формальности, то теряется смысл в использовании  Option Explicit - можно просто её не использовать
 
Цитата
nilske: теряется смысл в использовании  Option Explicit - можно просто её не использовать
я с вами спорить не буду (я не согласен, конечно), но вы так говорите, как будто с вас плату берут за использование этой опции. Это просто помощник, берущий на себя часть контроля и делающий это автоматически и безукоризненно.
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
Jack Famous, согласен - перегнул немного ))
имел ввиду что лучше подходить у этому осознанно, а не потому что "так надо" или с "меня же платы за это не возьмут"
 
Цитата
МатросНаЗебре написал:
Но в VBA этого ограничения нет.Изначально я объявлял переменные в начале процедуры/функции, так научили.
в  VBS подпрограмма или функция может быть описана в любом месте основного кода типа

Код
Dim A, B,С
a=Funca()
Function Funca()
   Funca=1
End Function
b=Funcb()
Function Funcb()
   Funcb=FuncA
End Function
С=A+B
Вот где поле для сюрпризов :-) Я когда первый раз столкнулся был сильно поражен . Сейчас уже не помню, проверял но результат не воспроизведу можно ли функцию внутри функции описать. Если да - то совсем можно запутать всех.


Ушли от темы про быстродействие
По вопросам из тем форума, личку не читаю.
 
Цитата
БМВ написал:
Если что-то работает медленно - это не значить что оно потребляет мало ресурсов, скорее наоборот, потребляет много, а выполняется долго - береги планету, не грей воздух
Цитата
evgeniygeo написал:
Если задача разовая, то не стоит сильно заморачиваться по скорости (в разумных пределах). Такие задачи у меня сейчас часто появляются в связи с локализацией различных штук в компании2) Если задача постоянная, то однозначно стоит бороться за скорость, но тоже нужно понимать, кто пишет код, т.к. трудозатраты могут быть не рациональными для этого
Это всё понятно, но вопрос был не об этом.
То, что за скорость нужно бороться - это понятно. Не понятно другое: когда я в теме вижу, как кто-то выкладывает код, говорит, что на 50000 строках он отрабатывает минуту и просит помочь его оптимизировать, ему выкладывают варианты, и в итоге он пишет: "После всех изменений код стал выглядеть так: сам код. На 50000 строках код отрабатывает за 3 секунды. Можно ли ещё как-то ускорить?". И возникает вопрос: ты и так его уже ускорил. Зачем ещё ускорять? Разве 3 секунды - это много? И до каких пор тогда ты будешь его ускорять? Ведь когда-то же надо остановиться. По мне, этот перфекционизим становится уже слишком маниакальным!
 
Цитата
написал:
По мне, этот перфекционизим становится уже слишком маниакальным!
И да и нет, есть такое понятие APDEX . Если в двух словах, то операция должна выполнятся по длительности с незначительными отклонениями от эталонного или принятого замера. Вот тут и начинается , что 3 сек для одного мало. а для другого долго.  представьте обработку длительностью 3 секунды информации которая поступает ежесекундно по несколько десятков записей. То есть за 3 секунды отчет уже устарел. Ну или просто ждать три сек долго.  
По вопросам из тем форума, личку не читаю.
 
Цитата
Счастливчик: Зачем ещё ускорять? Разве 3 секунды - это много?
иногда это просто интерес, какие подходы могут использоваться и/или какие условия должны быть соблюдены для большего ускорения.
Для кого-то 3 сек на 50 тыс строк это невероятно быстро, а для кого-то и 5 секунд на миллионе — это многовато.

Вот пример: я в надстройке на листе храню леммы (начальная форма) слов в виде пар "слово — лемма". Таких пар у меня 3,5 млн. Леммы используются в нескольких инструментах "нормализации" строк. Для работы каждого из них, все леммы нужно сначала загрузить в ОЗУ (в виде суперсловаря от bedvit'а). И вот, как вы думаете, что удобнее для пользователя — запустить нормализацию и уйти пить чай (3,5 млн / 50 тыс * 3 сек = 210 сек) или же подождать 3 секунды и получить результат? Вне зависимости от количества нормализуемых строк, леммы в словарь всегда грузятся ВСЕ. Или же пришлось бы сначала разбирать строки, собирая словарь слов, потом отбирать леммы только по этим словам и, только после этого, возвращаться к нормализации.

Скорость, которой достигаю я, обеспечивается глубокими исследованиями огромного количества вариантов.
А также библой bedvit'а  :D
Таким мало кто будет заниматься и часто — даже просто не поймёт, для чего это нужно. Ваша тема тому пример.
Изменено: Jack Famous - 27.04.2024 12:51:02
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
Jack Famous, офтоп
Скрытый текст
 
В Топ Гир было. Рассуждали про мотивацию решать сложные задачи. Обсуждая мост, говорили, что его можно было сделать из дерева и гораздо ниже, а сделали из титана и самым высоким. Потому что это круто )
https://youtu.be/HvaSqSCJaK0?si=odHv_Xlod_8qc7Fg
Изменено: МатросНаЗебре - 27.04.2024 14:34:39
 
Итак, зачем и когда мне потребовалось думать о секундах не с высока.
Допустим у меня есть вот такая номограмма

на которой две зависимости
Go = f(N, Qп) и Go = f(N, Gчсд)
обе зависимости я оцифровал, и соответственно получил два макроса позволяющих произвести расчёт Go по (N, Qп) и (N, Gчсд) соответственно. А вот теперь мне понадобилось по полученным  Go  и  N получить Gчсд.
Самый простой вариант - в лоб перебором, задавая устраивающую точность.
Цитата
Public Function fun_PT80_2st_Gsd_poG0N(G0 As Single, N As Single) As Single
Dim i As Single
fun_PT80_2st_Gnd_poG0N = 0 'Если решение не будет найдено - будет выведен 0
For i = 8 To 280 Step 0.01
   If Abs(fun_PT80_2st_G0poGsd(N, i) - G0) < 0.1 Then
       fun_PT80_2st_Gsd_poG0N = i
       Exit For
   End If
Next i
End Function
работает? Несомненно. Время расчёта как бы не особо большое - около 0.1 с. И я успокоился. А потом, спустя несколько месяцев, потребовалось производить н еодин такой расчёт, а несколько сотен (и таких расчётов тоже не один десяток). Вот тут то мне и пришлось вспоминать методы численные... Половинного деления в частности. А иначе дно.

УПД. Немного больше кода


И прирост скорости в сто раз

Оно того стоит...
Изменено: tutochkin - 06.05.2024 12:53:05
 
Сейчас попробовал на питоне:

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

итоговое время: 0,01с.

/c открытием файла - 0, 09с./

скрины
Изменено: nilske - 05.05.2024 12:05:19
 
А на VBA можно написать класс-коллекцию и добавлять данные туда данные очинь быстро, на питоне наверное низя..
Изменено: testuser - 05.05.2024 14:41:52
Страницы: 1
Наверх