Что более быстро, включите строку или elseif на типе?

Я могу пропускать что-то, но разве Вы не могли сделать оператора переключения на типе вместо Строки? Таким образом,

switch(childNode.Type)
{
case Bob:
  break;
case Jill:
  break;
case Marko:
  break;
}

Включите строку, в основном компилируется в if-else-if лестничную структуру. Попытайтесь декомпилировать простой. В любом случае тестирование строкового равенства должно быть более дешевым, так как они интернируются и все, что было бы необходимо, проверка ссылки. Сделайте то, что имеет смысл с точки зрения пригодности для обслуживания; если Вы - строки compring, сделайте строковый переключатель. Если Вы выбираете на основе типа, лестничная структура типа является более соответствующим.

Помните, профилировщик является Вашим другом. Любые догадки являются пустой тратой времени большую часть времени. BTW, у меня был хороший опыт с JetBrains профилировщик dotTrace .

Одна из проблем, которые Вы имеете с переключателем, использует строки, как "Bob", это вызовет намного больше циклов и строк в скомпилированном коде. IL, который сгенерирован, должен будет объявить строку, установить ее на "Bob", тогда используют его в сравнении. Таким образом с этим в памяти Ваши операторы IF будут работать быстрее.

пз. Привычка вечности в качестве примера работает, потому что Вы не можете включить Типы. (Не я не знаю, почему точно, но мы попробовали его, это не работает. Это имеет отношение к типу, являющемуся переменным)

, Если Вы хотите протестировать это, просто создать отдельное приложение и создать два простых метода, которые делают то, что описано выше, и используйте что-то как Ildasm.exe для наблюдения IL. Вы заметите намного меньше строк в IL Метода оператора IF.

Ildasm идет с VisualStudio...

страница ILDASM - http://msdn.microsoft.com/en-us/library/f7dy01k1 (По сравнению с 80) Учебным руководством по .aspx

ILDASM - http://msdn.microsoft.com/en-us/library/aa309387 (По сравнению с 71) .aspx

Три мысли:

1), Если Вы собираетесь сделать что-то другое на основе типов объектов, могло бы иметь смысл перемещать то поведение в те классы. Тогда вместо переключателя или если еще, Вы просто назвали бы childNode. DoSomething ().

2) Выдерживающие сравнение типы будут намного быстрее, чем сравнения строк.

3) В, если еще дизайн, Вы могли бы быть в состоянии использовать в своих интересах переупорядочение тестов. Если объекты "Jill" составляют 90% объектов, проходящих там, теста для них сначала.

Конечно, переключатель на Строке скомпилировал бы вниз в Сравнение строк (один на случай), который медленнее, чем сравнение типов (и намного медленнее, чем типичное целое число выдерживает сравнение, который используется для переключателя/случая)?

Если типы, которые Вы включаете, являются примитивными типами.NET, можно использовать Тип. GetTypeCode (Тип), но если они - пользовательские типы, они все возвратятся как TypeCode. Объект.

словарь А с делегатами или классами обработчика мог бы работать также.

Dictionary<Type, HandlerDelegate> handlers = new Dictionary<Type, HandlerDelegate>();
handlers[typeof(Bob)] = this.HandleBob;
handlers[typeof(Jill)] = this.HandleJill;
handlers[typeof(Marko)] = this.HandleMarko;

handlers[childNode.GetType()](childNode);
/// ...

private void HandleBob(Node childNode) {
    // code to handle Bob
}

Я вспоминаю чтение в нескольких справочниках, что, если/еще ветвление более быстро, чем оператор переключения. Однако немного исследования в области Blackwasp показывает, что оператор переключения на самом деле быстрее: http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx

В действительности, если Вы сравниваете типичные 3 - 10 (или так) операторы, я серьезно сомневаюсь, что существует любое реальное увеличение производительности с помощью один или другой.

, Поскольку Chris уже сказал, пойдите для удобочитаемости: , Что более быстро, включите строку или elseif на типе?

Если Вы уже не записали это и находите, что у Вас есть проблема производительности, я не волновался бы, о котором более быстро. Пойдите с тем, который это более читаемо. Помните, "Преждевременная оптимизация является корнем всего зла". - Donald Knuth

Попытайтесь использовать перечисления для каждого объекта, можно включить перечисления быстро и легко.

Оператор переключения быстрее для выполнения, чем if-else-if лестничная структура. Это происходит из-за способности компилятора оптимизировать оператор переключения. В случае if-else-if лестничной структуры код должен обработать каждого если оператор в порядке, определенном программистом. Однако, потому что каждый случай в операторе переключения не полагается на более ранние случаи, компилятор в состоянии переупорядочить тестирование таким способом как для обеспечения самого быстрого выполнения.

Если бы Вам сделали классы, я предложил бы использовать шаблон разработки Стратегии вместо переключателя или elseif.

Конструкция ПЕРЕКЛЮЧАТЕЛЯ была первоначально предназначена для целочисленных данных; это полно решимости, должен был использовать аргумент непосредственно в качестве индекса в "таблицу отправки", таблицу указателей. По сути, был бы единственный тест, затем запустился бы непосредственно к соответствующим нормам, а не серии тестов.

трудность здесь состоит в том, что это - использование, был обобщен для "представления в виде строки" типов, которые, очевидно, не могут использоваться в качестве индекса, и все преимущество конструкции ПЕРЕКЛЮЧАТЕЛЯ потеряно.

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

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

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

, например,

class Node
{
    public virtual void Action()
    {
        // Perform default action
    }
}

class Bob : Node
{
    public override void Action()
    {
        // Perform action for Bill
    }
}

class Jill : Node
{
    public override void Action()
    {
        // Perform action for Jill
    }
}

Затем вместо того, чтобы делать оператор переключения, Вы просто называете childNode. Действие ()

Я просто реализовал быстрое тестовое приложение и представил его с МУРАВЬЯМИ 4.
Спецификация:.Net 3.5 sp1 в Windows XP на 32 бита, код создается в режиме выпуска.

3 миллиона тестов:

• Переключатель: 1,842 секунды
• , Если: 0,344 секунды.

, Кроме того, результаты оператора переключения показывают (неудивительно), что более длинные имена занимают больше времени.

1 миллион тестов

• Bob: 0,612 секунды.
• Jill: 0,835 секунды.
• Marko: 1,093 секунды.

я похож, "Если Еще" быстрее, по крайней мере, сценарий, я создал.

class Program
{
    static void Main( string[] args )
    {
        Bob bob = new Bob();
        Jill jill = new Jill();
        Marko marko = new Marko();

        for( int i = 0; i < 1000000; i++ )
        {
            Test( bob );
            Test( jill );
            Test( marko );
        }
    }

    public static void Test( ChildNode childNode )
    {   
        TestSwitch( childNode );
        TestIfElse( childNode );
    }

    private static void TestIfElse( ChildNode childNode )
    {
        if( childNode is Bob ){}
        else if( childNode is Jill ){}
        else if( childNode is Marko ){}
    }

    private static void TestSwitch( ChildNode childNode )
    {
        switch( childNode.Name )
        {
            case "Bob":
                break;
            case "Jill":
                break;
            case "Marko":
                break;
        }
    }
}

class ChildNode { public string Name { get; set; } }

class Bob : ChildNode { public Bob(){ this.Name = "Bob"; }}

class Jill : ChildNode{public Jill(){this.Name = "Jill";}}

class Marko : ChildNode{public Marko(){this.Name = "Marko";}}

Я думаю, что основная проблема производительности здесь, что в блоке переключателя, Вы сравниваете строки, и что в, если еще блок, Вы проверяете на типы... Те два не являются тем же, и поэтому, я сказал бы, что Вы "сравниваете картофель с бананами".

я запустил бы путем сравнения этого:

switch(childNode.Name)
{
    case "Bob":
        break;
    case "Jill":
        break;
    case "Marko":
      break;
}

if(childNode.Name == "Bob")
{}
else if(childNode.Name == "Jill")
{}
else if(childNode.Name == "Marko")
{}

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

Переключатель () скомпилирует еще для кодирования эквивалентный ряду IFS. Сравнения строк будут намного медленнее, чем сравнения типов.