Список проголосовавших за комментарий "<p>Mikhail Sukhov, те, кто плохо знают, как работают структуры данных и GC, могут запросто в своем алгоритме написать какую-нибудь мега-лямбду с LINQ, которая вместо O(1) или O(log(n)) будет <a href="/r.php?u=http%3A%2F%2Faccidentallyquadratic.tumblr.com%2F&s=1595300071" target="_blank">O(n^2)</a>, и/ли new() во внутреннем цикле и мусорить так, что старания первой категории писателей платформы становятся напрасны при многомерной оптимизации на коротких таймфреймах и длинных данных. Сам грешил и видел такое, что специально не придумать. Как пример, буквально вчера бродил по ГитХабу в поисках новых репо на тему торговли, обратил внимание на <a href="/r.php?u=https%3A%2F%2Fgithub.com%2Ffastquant%2Ffastquant.dll%2Fblob%2Fmaster%2Fsrc%2FFastQuant%2FIndicators%2FSMA.cs%23L69&s=4100974278" target="_blank">этот метод</a> — вычисляют сумму полностью каждый раз (это O(n)) да еще и через Range (sic!), хотя могли бы добавлять новое значение и вычитать выбывающее значение (это O(1)), у вас в S# как бы почти так <a href="/r.php?u=https%3A%2F%2Fgithub.com%2FStockSharp%2FStockSharp%2Fblob%2Fmaster%2FAlgo%2FIndicators%2FSimpleMovingAverage.cs%23L58&s=897181157" target="_blank">и сделано</a>, но безобидный и удобный метод Sum() пересчитывает сумму каждый раз заново. Также вы или копите все значения инпута в буфере, или строчкой выше удаляете первый элемент, что для List тоже строго O(n) и много мусора — я с первого взгляда не понял, что значит isFinal. В Lean тоже используют List как буффер, но только как внутренний контейнер для <a href="/r.php?u=https%3A%2F%2Fgithub.com%2FQuantConnect%2FLean%2Fblob%2Fmaster%2FCommon%2FIndicators%2FRollingWindow.cs%23L39&s=3445112213" target="_blank">circular buffer</a>, который гарантирует смещение за O(1). Затем для рассчета суммы они вычитают <a href="/r.php?u=https%3A%2F%2Fgithub.com%2FQuantConnect%2FLean%2Fblob%2Fmaster%2FIndicators%2FSum.cs%23L67&s=1948396798" target="_blank">выбывающую точку и добавляют новую точку</a>, что также O(1). И это только для одного простейшего индикатора — а если их много вложенных, и надо прооптимизировать минутки честно walk-forward на большой решетке параметров, такие мелочи приводят к тому, что кто-то делает рассчет за пару минут, а кто-то — полчаса. Первые за час могут подкрутить стратегию много раз, пока вторые греют чай на процессоре :) На тему «бесполезности таких знаний» и premature optimization — мой <a href="/r.php?u=http%3A%2F%2Fjoeduffyblog.com%2F2010%2F09%2F06%2Fthe-premature-optimization-is-evil-myth%2F&s=4017013909" target="_blank">любимый пост</a> от гуру производительности, в котором есть еще примеры.<br/> <br/> </p><p>(не шума ради дублирую, случайно удалил оригинальный коммент, но он сохранился в другом месте)</p>"