в Delphi по замеру скорость отработки любого , даже простейшего запроса показывает около 100мс.
Выяснил что это тормозит отладчик Delphi. Если запускать не из отладки, достаточно даже сделать Detach, скорость обработки запроса улучшается до 10мс.
При обработке REST создается поток. Такой же эффект наблюдался при создании нескольких десятков потоков - под отладкой все тормозит, а без отладки нормально работает.
Пробовал Options / Debugger / EventLog / Thread Messages - отключать - не помогает. Как eскорить работу с потомками под отладкой? Когда саму отработки потоков отлаживать не требуется?
Стикер
Стикер
Стикер
Я делал вывод отладочных сообщений в логи, причем даже не в файл, а в UDP (syslog).
заметно тормозят обычно не просто брейкпойты а брейкпойты с условием. про "скрытые" брейкпойнты я не в курсе. если что то такое срабатывает при входе в воток, то мой вопрос как раз как это отключить
у меня логи заоптимизированы и закэширонавны, в файл, например я не использую в логах ни format, ни стандартную конкатенацию строк, даже функция формирования строки времени у меня своя, в 40 раз быстрее стандартной. в файл логи пишутся не чаще раза в секунду, максимум 10 мс. И если бы логи тормозили, тормозили бы одинаково под отладкой и без.
ниче я от этого не хочу,т.к. не пользуюсь. если нужен брейкпойнт с условием, пишу это условие в код
ЛЮБОЕ наблюдение и логирование оказывает существенное влияние. Хочется тормознуть обработку - добавь прогрессбар. Серьезно. Больше и меньше. А дальше нужно принимать решение, что важнее и как этого добиться.
А потокобезопасность есть? Я еще делал дамп стека при исключениях (через Jedi), и разматывание цепочек исключений (повторные raise).
На современном железе вообще пофиг, там моща лютая совершенно, можно трекать мегабайт логов в секунду и это отнимет 0% производительности.
если к моще так относиться - никакой мощи не хватит
Если при каждой записи лога файл открывать, сикать, писать и закрывать - то да, не хватит. =)
Поэтому я трекаю через syslog (UDP)
чушь, я переписывал код за коллегой, логирование занимало на порядок дольше времени чем исполнение, для того чтобы свысти логирование к приемлемым значеням, пришлось 1. исключить format 2. исключить конкатенацию строк 3. написать свое преобразование вррмени в строку 4. выкинуть сторонний фреймворк логирования 5. использовать Ansistring вместо string. и тогда получилось писать порядка сотни метров / сек логов
тут уже лог есть основная задача)))
нет лог отладочный. но нужен
Тут главное 4-й пункт (полагаю, из-за корявости работы с файлом), остальное не критично. Ну, может еще 5-й пункт влияет в случае WideChar. А первые пункты не актуальны, если есть FASTMM.
думаю в 5 имелся ввиду shortstring, иначе разницы нет
Создание потоков тормозит и разрушение тоже Тоже замечал Без отладчика 10к потоков создаётся моментально, под отладчиком - ждать надо
сталкивался с тем, что "производительность" витков под отладчиком совсем не та - если, скажем, голое приложение по витку на ядро может загрузить проц на 90%, то под отладчиком - только 30
Зачем ты вообще замеряешь скорость под отладкой?
я добиваюсь чтобы логирование занимало до 1% максимум 5% от времени исполнения. мои логи работают как минимум на порядок быстрее "стандартных" польза от них перекрывает эти затраты
Не знаю что ты делаешь не так, но у меня рест сервер даже под отладкой отвечает 20мс (и это не пустой запрос)
Есть несколько логов для разных задач . Есть простые однопоточные, есть многопоточные блокирующие, есть с неблокирующей очередью. Дамп стека в клиентских приложениях делаем через madexcept, для серверного другое решение, тут в канале давали. jedi не работает под линукс. Пока не хватает решения, как логировать , чтобы были видны все строчки лога перед крашем, но не писать каждое изменение в файл, и не использовать внешние фреймворки.
В консоль всё пиши и демон будет запоминать вывод
У меня особый случай. и клиент и сервер в данном случае находятся в одном процессе. Соответcтвенно поток создаваемы для rest тоже создается в том же процессе под отладкой и тормозит. Собственно вопрос был не про rest а про потоки. если отладки нет все отлично. понимаю что мне скажут что так делать не правильно, но так получается очень эффективно разрабатывать и отлаживать трехзвенку.
Зачем так делать? Клиента и сервер в одном процессе?
ОЧень продуктивно получается мигрировать от монолита к REST
Скорость замеряется постоянно, выходить из отладки для замера просто неудобно. Во всех других случаях проблем с этим нет.
Епрст. Ну так ты зачем вообще это делать, если ты отлаживаешь приложение?
Логирование вообще не должно занимать времени.
Обсуждают сегодня