вопрос простой : почему после закрытия скрипта (в частности который выбирал много памяти при оптимизации) программа не сбрасывает лишнюю память? даже при закрытии всех скриптов....

Только перезагрузка программы.

это известно, но что мешает программе высвобождать лишнюю память самостоятельно? это решило бы многие проблемы..

проблемы с памятью не только связаны с программой. Есть еще проблема фрагментации памяти в net framework. Она не высвобождается сама. Больше ничего внятного не могу сказать

Так ведет себя не столько программа, сколько .net framework. Фреймворк не спешит освобождать выделенную ранее и уже не используемую программой память, чтобы не задерживать ее исполнение. Когда свободная память кончится, тогда он и начнет полную перетряску.
В принципе, можно поставить новую версию Microsoft .NET Framework 4.5.1, в ней, по многолетним просьбам трудящихся, сделали-таки фоновую оптимизацию размещения больших блоков памяти. Это должно улучшить производительность и, по идее, снять проблему фрагментации памяти, но боюсь визуально большой разницы в работе программы заметно не будет. Хотя кто знает... Может Nectodron найдет минутку времени и черкнет пару строк по этой теме, он наверняка уже поизучал этот вопрос.

скажи плз, проверял 4,5,1 или может сравнивал эффект?

Я поставил 4.5.1 на одной машине, вроде все работает, включая лабу. Визуально программы работают также как и раньше, может быть чуть быстрее, но объективно не сравнивал.

проверил , ускорило оптимизацию на 2 мин при изначальных 26мин. хотя чистоту эксперемента не гарантирую

целых 7.69 % - это немало, по моему, не ожидал.

другая штука появилась - проци задействуются не более чем на 70%

если ваша стратегия не шибко ресурсоемкая так и будет. Из за процессов синхронизации будут вроде бы недогрузы проца.

до замены на .NET Framework 4.5.1 при оптимизации 8 ядер i7проца грузились на 99%. и это на одном и томже скрипте. я подозреваю что есть какой-то ньюанс который подкорректировать могут только разработчики tslab.

заведите скрипт на 1000 баров на двух скользящих. сделайте чтобы пересчетов было много. тыщ 500. посмотрите загрузку проца. ее не будет скорее всего.

ни когда такого небыло, кроме времени( а оно супер дорогое) еще это отражается на точности прогноза времени оптимизации. прогноз постоянно меняется хаотично. у меня было такое на компе у которого памяти мало было ,ну там от понятно -файл подкачки и все такое. вообще этот .net фреймворк редкая зараза.

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

господа разработчики , рассудите нас .

На 2 ядрах - все как и раньше (см. рис).
Один ньюанс есть в настройках программы - "Кол-во потоков оптимизации". Если там указать 1 - то загрузка CPU (на моем компе) будет около 50%, если 100 - то процентов 60, причем после некоторого времени работы программа тупо закрылась без лишних вопросов. ) Оптимально, наверное, 0 ставить, ну или кол-во потоков процессора (для i7 - 8)
Думаю, реально все сильно зависит от скрипта, какие индикаторы рассчитываются и сколько их, какие данные подгружаются, помещаются ли они в кеш, и даже дефрагментирован ли диск или нет.
Сторонние программы, особенно те которые норовят энергопотребление экономить, вполне могут ограничивать загрузку или частоту проца. Да и сами счетчики загрузки CPU - тоже неизвестно насколько точно и эффективно они работают.

достаточно надежно