Фильтрация массива с несколькими поисками значения ключа в PHP

Используйте отладочную сборку, и вы увидите разницу более четко. При отладочной сборке первый запуск покажет местоположение как строку throw ex, а второй - как происходящий из фактического вызова BadGuy. Очевидно, что "проблема" заключается в вызове BadGuy, а не в строке throw ex, и вы будете гоняться за меньшим количеством призраков, используя прямой оператор throw;.

При такой малой глубине стека преимущества не столь очевидны, при очень глубоком стеке вы замаскируете реальный источник проблемы и потеряете некоторую точность, вручную выбрасывая исключение вместо использования встроенного оператора re-throw.

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

Я подозреваю, что происходит то, что инлайнинг компилятора просто заменил вызов BadGuy() на throw new Exception();, потому что это единственное утверждение в BadGuy().

Если отключить опцию 'Optimize code' в окне свойств проекта -> Build, то и Release и Debug сборка дают одинаковый результат, который показывает BadGuy() в верхней части трассировки стека.

Кстати, я обнаружил хак один раз опубликовал в блоге (с тех пор я потерял ссылку), который позволяет вам сохранить стек вызовов при повторном вызове. Это в основном полезно, если вы перехватываете исключение в одном контексте (например, в потоке, выполняющем асинхронную операцию) и хотите повторно выбросить его в другом (например, в другом потоке, запустившем асинхронную операцию). Он использует некоторые недокументированные функции, позволяющие сохранять трассировки стека через границы удаленного взаимодействия.

    //This terrible hack makes sure track trace is preserved if exception is re-thrown
    internal static Exception AppendStackTrace(Exception ex)
    {
        //Fool CLR into appending stack trace information when the exception is re-thrown
        var remoteStackTraceString = typeof(Exception).GetField("_remoteStackTraceString",
                                                                 BindingFlags.Instance |
                                                                 BindingFlags.NonPublic);
        if (remoteStackTraceString != null)
            remoteStackTraceString.SetValue(ex, ex.StackTrace + Environment.NewLine);

        return ex;
    }

Похоже, JIT-оптимизаторы немного поработали. Как видите, стек вызовов во втором случае отличается от первого, когда вы запускаете сборку Debug. Однако в сборке Release оба стека вызовов идентичны из-за оптимизации.

Чтобы увидеть, что это связано с дрожанием, вы можете украсить методы атрибутом MethodImplAttribute :

[MethodImpl(MethodImplOptions.NoOptimization)]
private static void ThrowWithoutVariable()
{
    try
    {
        BadGuy();
    }
    catch
    {
        throw;
    }
}

Обратите внимание, что IL по-прежнему отличается для ThrowWithoutVariable и . ThrowWithVariable:

.method private hidebysig static void  ThrowWithVariable() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .locals init ([0] class [mscorlib]System.Exception ex)
  .try
  {
    IL_0000:  call       void Ex::BadGuy()
    IL_0005:  leave.s    IL_000a
  }  // end .try
  catch [mscorlib]System.Exception 
  {
    IL_0007:  stloc.0
    IL_0008:  ldloc.0
    IL_0009:  throw
  }  // end handler
  IL_000a:  ret
} // end of method Ex::ThrowWithVariable

.method private hidebysig static void  ThrowWithoutVariable() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .try
  {
    IL_0000:  call       void Ex::BadGuy()
    IL_0005:  leave.s    IL_000a
  }  // end .try
  catch [mscorlib]System.Object 
  {
    IL_0007:  pop
    IL_0008:  rethrow
  }  // end handler
  IL_000a:  ret
} // end of method Ex::ThrowWithoutVariable

Обновите, чтобы ответить на ваш последующий вопрос, соответствует ли это спецификации CLI

На самом деле соответствует, а именно позволяет JIT-компилятору выполнять важные оптимизации. Приложение F гласит на странице 52 (выделено мной):

Некоторые CIL-инструкции выполняют неявные проверки во время выполнения, которые гарантируют память и безопасность типа. Изначально интерфейс командной строки гарантировал, что исключения были точный , что означает, что состояние программы был сохранен, когда было исключение брошенный. Однако обеспечение точного исключения для неявных проверок делает некоторые важные оптимизации практически невозможно применить. Теперь программисты могут объявить через настраиваемый атрибут, что метод «расслабленный», что говорит о том, что исключения возникающие из-за неявных проверок во время выполнения не нужно быть точным.

Расслабленные чеки сохранить проверяемость (путем сохранения память и безопасность типов), в то время как разрешение оптимизаций, которые изменяют порядок инструкции. В частности, это включает следующие оптимизации:

• Подъем неявных проверок во время выполнения петель.
• Переупорядочивание итераций цикла (например, векторизация и автоматическая многопоточность)
• Переключение циклов
• Встраивание, которое делает встроенный как минимум так же быстро, как эквивалентный макрос