Double.TryParse або Convert.ToDouble - що швидше і безпечніше?

Моя програма читає файл Excel за допомогою VSTO і додає дані прочитаного до StringDictionary. Він додає лише дані, що є числами з кількома цифрами (1000 1000,2 1000,34 - кома є роздільником у російських стандартах).

Що краще перевірити, чи поточний рядок є відповідним числом?

object data, string key; // data had read

try
{
  Convert.ToDouble(regionData, CultureInfo.CurrentCulture);
  dic.Add(key, regionData.ToString());
}
catch (InvalidCastException)
{
  // is not a number
}

або

double d;
string str = data.ToString();
if (Double.TryParse(str, out d)) // if done, then is a number
{
  dic.Add(key, str);
}

Я повинен використовувати StringDictionaryзамість цього Dictionary<string, double>через наступні проблеми алгоритму аналізу.

Мої запитання: Який шлях швидший? Що безпечніше?

А краще зателефонувати Convert.ToDouble(object)чи Convert.ToDouble(string)?

Я провів швидкий ненауковий тест у режимі звільнення. Я використав два входи: "2.34523" і "badinput" для обох методів і повторив 1 000 000 разів.

Дійсне введення:

Double.TryParse = 646ms
Convert.ToDouble = 662 ms

Не сильно відрізняється, як очікувалося. Для всіх намірів і цілей, для дійсного введення вони однакові.

Неправильні дані:

Double.TryParse = 612ms
Convert.ToDouble = ..

Ну .. це тривало довго. Я повторив все, використовуючи 1000 ітерацій, і Convert.ToDoubleз поганим введенням зайняв 8,3 секунди. В середньому це зайняло б більше 2 годин. Мені байдуже, наскільки базовим є тест, у випадку недійсного введення Convert.ToDoubleпідняття винятків зіпсує вашу продуктивність.

Отже, ось ще один голос за TryParseз кількома цифрами, щоб підтвердити це.

Для початку я б скористався, double.Parseа не Convert.ToDoubleспочатку.

Щодо того, чи слід вам використовувати, Parseабо TryParse: чи можете ви продовжити, якщо є вхідні дані погані, чи це справді виняткова умова? Якщо це виняткове, використовуйте Parseі дайте йому підірватися, якщо вхід поганий. Якщо це очікується і з вами можна чисто поводитися, використовуйте TryParse.

Рекомендації щодо розробки .NET Framework рекомендують використовувати методи Try. Уникнення винятків, як правило, є гарною ідеєю.

Convert.ToDouble(object) зроблю ((IConvertible) object).ToDouble(null);

Який подзвонить Convert.ToDouble(string, null)

Тому швидше викликати рядок.

Однак версія рядка просто робить це:

if (value == null)
{
    return 0.0;
}
return double.Parse(value, NumberStyles.Float | NumberStyles.AllowThousands, provider);

Тож швидше зробити double.Parseбезпосередньо.

Якщо ви не збираєтеся обробляти виняток, скористайтеся TryParse. TryParse працює швидше, оскільки йому не потрібно мати справу з усією трасою стеку винятків.

Як правило, я намагаюся уникати Convertкласу (мається на увазі: я його не використовую), тому що я вважаю це дуже заплутаним: код дає занадто мало натяків на те, що саме тут відбувається, оскільки Convertдозволяє виконувати багато семантично дуже різних перетворень з одним і тим же кодом . Це ускладнює контроль програміста, що саме відбувається.

Тому моя порада - ніколи не користуватися цим класом. Це насправді також не потрібно (за винятком двійкового форматування числа, оскільки звичайний ToStringметод класів чисел не пропонує відповідного методу для цього).

Якщо ви не впевнені на 100% у своїх введеннях, що рідко буває, вам слід використовувати Double.TryParse.

Convert.ToDouble will throw an exception on non-numbers
Double.Parse will throw an exception on non-numbers or null
Double.TryParse will return false or 0 on any of the above without generating an exception.

Швидкість розбору стає другорядною, коли ви видаєте виняток, оскільки там не набагато повільніше, ніж виняток.

Тут багато ненависті до класу Convert ... Щоб трохи збалансувати, є одна перевага для Convert - якщо вам вручають об’єкт,

Convert.ToDouble(o);

може просто повернути значення легко, якщо o вже є Double (або int, або що-небудь легко випробовуване).

Використання Double.Parse або Double.TryParse чудово, якщо у вас це вже є в рядку, але

Double.Parse(o.ToString());

має піти зробити рядок , щоб бути розібрана першої і в залежності від вашого входу , які можуть бути більш дорогими.

Double.TryParse IMO.

Вам простіше впоратися, Ви точно знатимете, де сталася помилка.

Тоді ви можете впоратися з цим, як вважаєте за потрібне, якщо воно повертає false (тобто не вдалося перетворити).

Я завжди віддавав перевагу використанню TryParse()методів, оскільки це призведе до успіху або невдалого перетворення, не турбуючись про винятки.

Це цікаве старе питання. Я додаю відповідь, оскільки ніхто не помітив декількох речей із початковим запитанням.

Що швидше: Convert.ToDouble або Double.TryParse? Що безпечніше: Convert.ToDouble або Double.TryParse?

Я збираюся відповісти на обидва ці питання (відповідь оновлю пізніше), докладно, але спочатку:

З міркувань безпеки, що кожен програміст пропустив у цьому питанні, це рядок (наголос мій):

Він додає лише дані, що є числами з кількома цифрами (1000 1000,2 1000,34 - кома є роздільником у російських стандартах ).

Далі йде цей приклад коду:

Convert.ToDouble(regionData, CultureInfo.CurrentCulture);

Цікавим тут є те, що якщо електронні таблиці мають російський формат чисел, але Excel неправильно набрав поля комірок, яка правильна інтерпретація значень, що надходять з Excel?

Ось ще одна цікава річ щодо двох прикладів щодо швидкості:

catch (InvalidCastException)
{
    // is not a number
}

Це, швидше за все, буде генерувати MSIL, який виглядає так:

catch [mscorlib]System.InvalidCastException 
{
  IL_0023:  stloc.0
  IL_0024:  nop
  IL_0025:  ldloc.0
  IL_0026:  nop
  IL_002b:  nop
  IL_002c:  nop
  IL_002d:  leave.s    IL_002f
}  // end handler
IL_002f: nop
IL_0030: return

У цьому сенсі ми, мабуть, можемо порівняти загальну кількість інструкцій MSIL, виконуваних кожною програмою - про це пізніше, коли я оновлюватиму цю публікацію.

Я вважаю, що код повинен бути правильним, зрозумілим та швидким ... У такому порядку!

Особисто я вважаю, що TryParseметод легше читати, і який із них ви насправді хочете використовувати, залежить від вашого випадку використання: якщо помилки можна обробляти локально, ви очікуєте помилок, і бул від TryParseцього хороший, інакше ви можете просто дозволити винятки літають.

Я би також очікував, що TryParseце буде швидшим, оскільки це дозволяє уникнути накладних витрат на обробку винятків. Але для порівняння різних можливостей використовуйте контрольний інструмент, як MiniBench Джона Скіта .