Сообщение от
Payer
1) На мощной системе и быстром интернете почти всегда происходит схлопывание программы "Приложение будет закрыто...." при числе потоков 700-1000
Если система или интернет медленнее, то открытие такого числа не происходит и программа работает нормально. Это можно будет решить в следующих релизах?
Я вроде уже где-то говорил, что Router Core Library создаёт свой дополнительный внутренний поток при создании экземпляра объекта TRouter, а это означает, что в реальности потоков создаваться будет в 2 раза больше. В Windows кол-во потоков ограничено - где-то 1900 потоков на процесс.
Проблему можно решить, отказавшись от потоков в библиотеке, но пока не решён вопрос синхронизации, это всё не так просто.
Обходной путь на данный момент - ставить не более 500-600 потоков.
Сообщение от
Payer
2) Если загрузить список одной строкой процессор почти не грузится. Если этот же диапазон 64-128 тыс строк поштучно - сильно грузится процессор. Это неоптимальный алгоритм?
Можно ли будет встроить функцию объединения соседних строк в один диапазон?
Встраивание подобной функции только замедлит загрузку диапазонов... Честно, по части их оптимизации я уже сделал всё, что мог.
Сообщение от
Payer
3) Запускаем задачу сканирования часов на 12 (по строке состояния). Перебор идет бодро, трафик пошел. Часа через три начинает притормаживаться, время уже показывает часов 20-25. Через 12 часов уже сильно тормозит, трафик почти не идет, перебрано 30 процентов и типа осталось два дня. В чем здесь проблема? Куда идут ресурсы?
Полагаю, на генерацию таблицы гудов. Она регенерируется полностью по таймеру, иначе сделать пока нельзя. Попробуйте отключить генерацию гудов в настройках, а потом включить по окончанию сканирования.
Сообщение от
Payer
5) В одном случае из пяти внезапно останавливается подсчет гудов. На резульаты оно не влияет, но замечено такое на разных ПК и в разных условиях.
Знаю про возможность такого вылета, но его крайне сложно поймать, и починить соответственно.