WF subset тормозит (наблюдение)

[Artem.spb]

Поделюсь сегодняшним открытием.
Функция Get WF subset дико тормозная. Понимаю, конечно, что она универсальная и всё такое, но не на столько же.

Дали мне задачу впихнуть код в старый контроллер, а он не лезет. Стал копать, что именно тормозит, и через профайлер обнаружил, что эта функция выполняется дольше всего. Поменял её на примитивы, и всё летать стало.
Ради любопытства сделал тест, и результат "превзошёл" все ожидания.
К тому же в моей задаче мне нужно разделить массив на последовательные части, поэтому вычислений ещё меньше, но пара делений погоды не делает. Однако... использование этой функции можно оправдять только гигантской ленью или переизбытком вычислительной мощности.

Получается, что Get WF subset выполняется в миллион раз медленее, чем то же самое действие на примитивах

wf_res.JPG (12.04 КБ) 137 просмотров

[maxim_MA]

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

[Artem.spb]

В новых функциях полное бракоделие

Соглашусь, что порой там много мусора, но это не здоровый подход.
Готовые функции нужны для того, чтобы ускорять разработку, а не только тестировать концепции.
Иначе можно и до ассемблера дойти, или купить, например, Sount-vibration тулкит, протестировать гипотезу, а потом всё руками собирать.

[maxim_MA]

Sount-vibration тулкит, протестировать гипотезу, а потом всё руками собирать.

Когда-то так и сделал, когда нужна производительность все приходится разрабатывать под себя.
Даже мощные компы иногда не помогают