Первая конкретика по финансовому программированию!!! читать,обсуждать, проникаться!!!

Mikhail Sukhov, те, кто плохо знают, как работают структуры данных и GC, могут запросто в своем алгоритме написать какую-нибудь мега-лямбду с LINQ, которая вместо O(1) или O(log(n)) будет O(n^2), и/ли new() во внутреннем цикле и мусорить так, что старания первой категории писателей платформы становятся напрасны при многомерной оптимизации на коротких таймфреймах и длинных данных. Сам грешил и видел такое, что специально не придумать. Как пример, буквально вчера бродил по ГитХабу в поисках новых репо на тему торговли, обратил внимание на этот метод  — вычисляют сумму полностью каждый раз (это O(n)) да еще и через Range (sic!), хотя могли бы добавлять новое значение и вычитать выбывающее значение (это O(1)), у вас в S# как бы почти так и сделано, но безобидный и удобный метод Sum() пересчитывает сумму каждый раз заново. Также вы или копите все значения инпута в буфере, или строчкой выше удаляете первый элемент, что для List тоже строго O(n) и много мусора — я с первого взгляда не понял, что значит isFinal. В Lean тоже используют List как буффер, но только как внутренний контейнер для circular buffer, который гарантирует смещение за O(1). Затем для рассчета суммы они вычитают выбывающую точку и добавляют новую точку, что также O(1). И это только для одного простейшего индикатора — а если их много вложенных, и надо прооптимизировать минутки честно walk-forward на большой решетке параметров, такие мелочи приводят к тому, что кто-то делает рассчет за пару минут, а кто-то — полчаса. Первые за час могут подкрутить стратегию много раз, пока вторые греют чай на процессоре :) На тему «бесполезности таких знаний» и premature optimization — мой любимый пост от гуру производительности, в котором есть еще примеры.

(не шума ради дублирую, случайно удалил оригинальный коммент, но он сохранился в другом месте)