关于c#：测试对象类型的最有效方法

我将值存储为字符串，并存储在DataTable中，其中每个值实际上可以表示int，double或string(在从外部数据源导入过程中，它们全部转换为字符串) 。我需要测试并查看每个值的真正类型。

什么对应用程序更有效(或没有实际区别)？

将使用double.TryParse，它具有性能上的好处。

您遇到的麻烦是，在某些情况下答案可能是所有三种类型。

3可以是整数，双精度或字符串！

这取决于您要尝试执行的操作以及它们是特定类型的重要性。最好只保留它们尽可能长的时间，或者另辟a径，用一种方法来标记每个字符(如果您可以控制原始字符串的源代码)。

对于不同的方法，您将获得不同的结果，具体取决于是否使用优化进行编译。您基本上有几种选择：

您可以轻松地设置一个控制台应用程序，尝试每次10,000次，并返回每次的持续时间(测试o是int还是其他形式的时间)。

如果对象确实拥有一个int，则try-catch方法最快，如果没有，则最慢(甚至比GetType还要慢)。如果您有字符串，则int.TryParse很快，但是如果您有未知对象，它的速度就会变慢。

有趣的是，当o实际上是一个int时，.Net 3.5和优化打开o is int检查所花费的时间与try-catch相同。如果o实际上是其他东西，o is int只会稍微慢一点。

令人讨厌的是，如果您执行以下操作，FxCop会抛出警告：

但是我认为这是FxCop中的一个错误-它不知道int是一种值类型，因此建议您改用o as int。

如果输入始终是字符串，则int.TryParse最佳，否则is运算符最快。

当您有一个字符串时，我将查看是否需要知道它是一个整数，而不是一个整数。如果int.TryParse通过，那么double.TryParse也将通过，因此您可以将检查次数减半-返回double或string并在希望有整数的情况下将double取整。

我想说的是，不必为这样的微性能而担心。最好先做一些工作，然后使其尽可能简洁明了且易于阅读。您能做的最坏的事情是牺牲可读性，从而获得微不足道的性能。

最后，处理性能问题的最佳方法是在有表明实际性能问题的数据时保存它们，否则，您将花费大量时间进行微优化，从而导致更高的性能。以后的维护成本。

如果您发现这种解析情况确实是应用程序中的瓶颈，那么该是时候尝试找出解决问题最快的方法了。我认为Jeff(和其他许多人)已经在博客上写过很多这类事情。

我个人将使用int.tryparse，然后使用double.tryparse。这些方法的性能相当快。它们都返回一个布尔值。如果两者均失败，则根据定义数据的方式，您将获得一个字符串。