Действительно ли более эффективно сравнить ints и ints или строки и строки

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

Изменить: Для тех, кто интересуется, вот исходный код, быстрый и грязный:

using System;
using System.Diagnostics;

namespace CompareTest
{
    static class Program
    {
        static void Main(string[] args)
        {
            int iterations = 10000000;
            int a = 5;
            string b = "5";

            Stopwatch toStringStopwatch = new Stopwatch();
            toStringStopwatch.Start();

            for (int i = 0; i < iterations; i++) {
                bool dummyState = a.ToString() == b;
            }

            toStringStopwatch.Stop();

            Stopwatch parseStopwatch = new Stopwatch();
            parseStopwatch.Start();

            for (int i = 0; i < iterations; i++) {
                bool dummyState = a == int.Parse(b);
            }

            parseStopwatch.Stop();

            Console.WriteLine("ToString(): {0}", toStringStopwatch.Elapsed);
            Console.WriteLine("Parse(): {0}", parseStopwatch.Elapsed);
            Console.ReadLine();
        }
    }
}

Чем большее число я выберу для первого метода. а. если b не является числом, перед попыткой сравнения произойдет сбой. б. строка сравнивается сразу по длине и номеру.

I doubt either call will really significantly impact your application unless you really are creating something on a grand scale.

Both techniques are creating a new string, however int.ToString() has to perform a lot less tasks than int.Parse().

int.ToString() is performed internally in the CLR (comnumber). int.Parse() is done inside the BCL source using Number.ParseInt32() -> Number.StringToNumber() -> Number.ParseNumber().

ParseNumber performs a huge number of checks so from a finger in the air guess you would imagine int.ToString() is faster. As others have mentioned, a proper performance test with the StopWatch class will be a better way to find out. You will want to try this out with the number format you are expecting: decimal, hex.

You can compare the C++ that the CLR is using for ToString() here: Look for

• NumberToString (that's used for ToString() and other formats) which is used in FCIMPL3, called by int.ToString() as an extern call.
• Int32ToDecStr is used for the "D" formatter.

The C#

var x = 5.ToString("D");
var y = 5.ToString();

I could be wrong about FCIMPL3, please correct me if I am.

Также я читаю somwhere (MSDN), используя следующее быстрее, чем == для сравнения строк

StringA.ToUpperInvariant() == StringB.ToUpperInvariant()

Есть много способов представить одно и то же число в виде строки ...

Анализ строки в Int32 требует большей производительности и более чувствителен к ошибкам. В первую очередь вам нужно убедиться, что Int32.Parse будет успешным. Также вы можете использовать альтернативу для '=='. Используйте .Equals (), это проще для чтения и понимания.

if(b.Equals(a))
{

}

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

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

2. Когда я оказываюсь в затруднительном положении в коде, иногда полезно спросить себя: «Какие предположения или выбор поставили меня в эту ситуацию? Что я мог бы сделать по-другому?» Например (просто догадываясь), когда вы написали «... где много сравнений между int * [sic] * и строками», означает ли это, что вы можете использовать одни и те же значения неоднократно (например, Если да, не могли бы вы преобразовать каждую строку в int и кэшировать преобразованное значение для последующего повторного использования вместо того, чтобы преобразовывать его позже?

Your choice is between the following
Code Listing A

int a = 5;
string b = "5";
//Assuming these two values are input received by the application at runtime
int bInt;
if (int.TryParse(b, NumberStyles.None, CultureInfo.InvariantCulture, out bInt) 
    && a.Equals(bInt))
{

}

and

Code Listing B

int a = 5;
string b = "5"; 
//Assuming these two values are input received by the application at runtime
if (string.Compare(b, a.ToString(), StringComparison.Ordinal) != -1)
{

}

I have tested this with stopwatch (as given in the selected answer) and found Code Listing A to be much faster. Но листинг B более читабелен!

Листинг A превосходит if (a == int.Parse (b))

Внутри ToString и Parse делают следующее:

Parse

value = 0
for each char in string
  value = value * 10 + valueof(char) // i.e. '0' -> 0, '7' -> 7

ToString

string=""
while value > 0
  string.insert_at_front value % 10 // so that 0 -> '0' and 6 -> '6'
  value /= 10

// on IA32, the % and / can be done at the same time but requires
// a 64bit source for 32bit values

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

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