Dv
А
Benchmark2 получит от этого преимуществоSize: a a a
2020 January 26
Dv
Тупо из-за того, что он выполняется вторым
Dv
Бывает и обратная ситуация, когда первому выполняться легче (если тогда ещё не подгружены некоторые типы, и девиртуализация может лучше сработать).
Ln
@fvnever
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
Dv
Далее, нужно мешать JIT'у выбрасывать часть или все твои вычисления как не используемые
DB
Ну, банально, type initializer будет вызван в первом месте, где используется тип
Эх, а как реордоринг i/o и процедур учитывать ?
Dv
По дефолту он может внезапно оказаться умным, и испортит/переоптимизирует какой-нибудь бенч
Dv
Ну и замерять тоже надо умеючи, там куча сложной математики (не просто взять среднее или что-то такое)
A
@fvnever
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
То, что запускается раз в год — и тюнить до такой степени нет смысла...
Dv
Многие проблемы решены в BenchmarkDotNet (ну вы же знали, что я к этому клоню, да?), и для всех бенчей нужно использовать его. Ну или какую-то другую библиотеку бенчей, автор которой хоть слышал о перечисленных мной проблемах.
Dv
@fvnever
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
а поясни пожалуйста про прогревания
мне вот не понятно
я как юзер не буду же 20 раз запускать приложение что бы оно не тормозило
так почему нельзя бенчить на холодную
А это вот уже от целей тестирования зависит
Dv
Обычно мы бенчим горячий серверный код
Dv
Который миллион раз выполняется за время работы сервера
Ln
То, что запускается раз в год — и тюнить до такой степени нет смысла...
нет конечно
я при включении пк на ходных кешах запускаю приложение
и меня вымораживает что оно притормаживает вначале
и рискну предположить что часть того кода можно было бы чуть лучше пооптимизировать
я при включении пк на ходных кешах запускаю приложение
и меня вымораживает что оно притормаживает вначале
и рискну предположить что часть того кода можно было бы чуть лучше пооптимизировать
Dv
Однако, если тебе нужно консольный тул бенчить — то это другой разговор. Там общие законы будут такими же, как я перечислил, но конкретная методика тестирования (и вычисления/исключения влияния JIT) будет иной.
Dv
нет конечно
я при включении пк на ходных кешах запускаю приложение
и меня вымораживает что оно притормаживает вначале
и рискну предположить что часть того кода можно было бы чуть лучше пооптимизировать
я при включении пк на ходных кешах запускаю приложение
и меня вымораживает что оно притормаживает вначале
и рискну предположить что часть того кода можно было бы чуть лучше пооптимизировать
А тут у тебя, возможно, вообще в IO проблема и в дисковых кэшах. Нужно это профилировать и тогда уже делать выводы.
Dv
Эх, а как реордоринг i/o и процедур учитывать ?
JIT учитывает, вставляя опциональные вызовы тайп инитиалайзеров во все места, где он сомневается, нужны они или нет.
Dv
И это может заметно влиять на быстродействие микробенчмарков
Dv
Ну вон как у чувака выше
Dv
Где он создаёт строчки из двух байт