Использует делегатов чрезмерно плохой идеей для производительности?

Question

Рассмотрим следующий код:

if (IsDebuggingEnabled) { 
    instance.Log(GetDetailedDebugInfo()); 
} 

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

Теперь, уборщик альтернатива закодировать что-то вроде этого:

instance.Log(() => GetDetailedDebugInfo()); 

Где .log() определяется как:

public void Log(Func<string> getMessage) 
{ 
    if (IsDebuggingEnabled) 
    { 
     LogInternal(getMessage.Invoke()); 
    } 
} 

Моя забота с производительностью, предварительное тестирование Безразлично» t показывает, что второй случай будет особенно дорогим, но я не хочу сталкиваться с неожиданностями при увеличении нагрузки.

О, и, пожалуйста, не предлагайте условную компиляцию, потому что это не относится к этому случаю.

(PS: Я написал код прямо в StackOverflow Задать вопрос текстовое поле, так что не обессудьте, если есть тонкие ошибки и не компилирует, вы получите точку :)

Answer 1

Я надеялся на документацию относительно производительности в таких случаях, но мне кажется, что все, что у меня есть, - это советы о том, как улучшить мой код ... Никто, кажется, не читал мою P.S. - Нет очков для вас.

Так что я написал простой тест:

public static bool IsDebuggingEnabled { get; set; } 


    static void Main(string[] args) 
    { 
     for (int j = 0; j <= 10; j++) 
     { 
      Stopwatch sw = Stopwatch.StartNew(); 
      for (int i = 0; i <= 15000; i++) 
      { 
       Log(GetDebugMessage); 
       if (i % 1000 == 0) IsDebuggingEnabled = !IsDebuggingEnabled; 
      } 
      sw.Stop(); 
      Console.WriteLine(sw.ElapsedMilliseconds); 
     } 

     Console.ReadLine(); 
     for (int j = 0; j <= 10; j++) 
     { 
      Stopwatch sw = Stopwatch.StartNew(); 
      for (int i = 0; i <= 15000; i++) 
      { 
       if (IsDebuggingEnabled) GetDebugMessage(); 
       if (i % 1000 == 0) IsDebuggingEnabled = !IsDebuggingEnabled; 
      } 
      sw.Stop(); 
      Console.WriteLine(sw.ElapsedMilliseconds); 
     } 
     Console.ReadLine(); 
    } 

    public static string GetDebugMessage() 
    { 
     StringBuilder sb = new StringBuilder(100); 
     Random rnd = new Random(); 
     for (int i = 0; i < 100; i++) 
     { 
      sb.Append(rnd.Next(100, 150)); 
     } 
     return sb.ToString(); 
    } 

    public static void Log(Func<string> getMessage) 
    { 
     if (IsDebuggingEnabled) 
     { 
      getMessage(); 
     } 
    } 

Задержки, кажется, быть точно так же между этими двумя версиями. Я получаю 145 мс в первом случае и 145 мс во втором случае

Похоже, я ответил на свой вопрос.

Answer 2

вызова GetMessage Делегат вместо вызова Invoke на него.

if(IsDebuggingEnabled) 
{ 
    LogInternal(getMessage()); 
} 

Вы также должны добавить null check on getMessage.

Answer 3

Я считаю, что делегаты создают новый поток, поэтому вы можете быть прав об этом, увеличивая производительность. Почему бы не настроить тестовый прогон, как предложил Дав, и внимательно следить за количеством потоков, созданных вашим приложением, для этого вы можете использовать Process Explorer.

Подвешивание! Я исправлен! Делегаты используют только потоки, когда вы используете «BeginInvoke» ... поэтому мои приведенные выше комментарии не применяются к тому, как вы их используете.

Answer 4

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

Обратите внимание, что если вы хотите сделать это в сборках Debug, вы можете добавить атрибут [Conditional("DEBUG")] к методу журнала.

Answer 5

Вы также можете сделать это:

// no need for a lambda 
instance.Log(GetDetailedDebugInfo) 

// Using these instance methods on the logger 
public void Log(Func<string> detailsProvider) 
{ 
    if (!DebuggingEnabled) 
     return; 

    this.LogImpl(detailsProvider()); 
} 

public void Log(string message) 
{ 
    if (!DebuggingEnabled) 
     return; 

    this.LogImpl(message); 
} 

protected virtual void LogImpl(string message) 
{ 
    .... 
} 

Answer 6

Стандартные ответы:

• Если вам нужно сделать это, ты должен это сделать.
• Заверните его 10^9 раз, посмотрите на секундомер, &, который расскажет вам, сколько наносекунд требуется.
• Если ваша программа большая, возможно, у вас больше проблем в другом месте.

Answer 7

Существует разница в производительности. Насколько это важно, будет зависеть от остальной части вашего кода, поэтому я бы рекомендовал профилировать, прежде чем приступать к оптимизации.

Сказав, что для первого примера:

if (IsDebuggingEnabled) 
{ 
    instance.Log(GetDetailedDebugInfo()); 
} 

Если IsDebuggingEnabled является статическим, то только для чтения чек будет JITted прочь, как он знает, что он никогда не может измениться. Это означает, что приведенный выше пример будет иметь нулевое влияние на производительность, если IsDebuggingEnabled является ложным, потому что после завершения JIT код будет удален.

instance.Log(() => GetDetailedDebugInfo()); 

public void Log(Func<string> getMessage) 
{ 
    if (IsDebuggingEnabled) 
    { 
     LogInternal(getMessage.Invoke()); 
    } 
} 

Метод будет вызываться каждый раз после экземпляра instance.Log. Который будет медленнее.

Но прежде чем тратить время на эту микро-оптимизацию, вы должны профилировать приложение или выполнять некоторые тесты производительности, чтобы убедиться, что на самом деле это бутылочная горловина в вашем приложении.