在以下情况下,linq 技术的效率会降低多少,并且可以进行优化吗?

发布于 2024-11-03 06:22:23 字数 729 浏览 0 评论 0原文

在以下情况下,linq 技术的效率会降低多少,并且可以进行优化吗?

Linq 技术

public String FindProviderName(Int32? TrueName)
{
    String providerName = (from p in this.Providers
                           where p.TrueName == TrueName
                           select p.ProviderName).First().ToString();

    return providerName;
}

步行技术

public String FindProviderName(Int32? TrueName)
{
    String providerName = String.Empty;

    foreach (IProvider provider in this.Providers)
    {
        if (provider.TrueName == TrueName)
        {
            providerName = provider.ProviderName;
            break;
        }
    }

    return providerName;
}

How much less efficent would the linq technique be in the following case and could either be optimised?

Linq technique:

public String FindProviderName(Int32? TrueName)
{
    String providerName = (from p in this.Providers
                           where p.TrueName == TrueName
                           select p.ProviderName).First().ToString();

    return providerName;
}

Walking technique:

public String FindProviderName(Int32? TrueName)
{
    String providerName = String.Empty;

    foreach (IProvider provider in this.Providers)
    {
        if (provider.TrueName == TrueName)
        {
            providerName = provider.ProviderName;
            break;
        }
    }

    return providerName;
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

忘你却要生生世世 2024-11-10 06:22:23

如果那是 LINQ 到对象,那么它们都会非常快。如果您想要更快,请考虑使用 Dictionary 并使用 TryGetValue(...)。显然,您需要预先生成字典,也许可以通过 ToDictionary() 来生成。

请注意,当没有匹配时,显示的两个示例是不同的;一个投掷;一个返回一个空字符串。此外,无需对字符串调用 ToString()。


重新获得更快的版本(评论);您需要一个字段,

Dictionary<int,string> lookup;

并且在使用之前(或数据更改之后)的某个时刻您需要填充它:

lookup = providers.Where(p => p.RealName != null)
    .ToDictionary(p => p.RealName.Value,
        p => p.ProviderName);

那么您的查找将类似于:

string providerName;
if(realName == null ||
    !lookup.TryGetValue(realName.Value, out providerName))
    return null;
return providerName;

If that is LINQ-to-objects, they'll both be pretty fast. If you want faster, consider a Dictionary<int,string> and use TryGetValue(...). Obviously you need to pre-generate the dictionary, perhaps via ToDictionary().

Note that the two examples shown are different when there is no match; one throws; one returns an empty string. Also, there is no need to call ToString() on a string.


Re the faster version (comments); you need a field,

Dictionary<int,string> lookup;

And at some point prior to use (or after data changes) you need to populate it:

lookup = providers.Where(p => p.RealName != null)
    .ToDictionary(p => p.RealName.Value,
        p => p.ProviderName);

Then your lookup would be like:

string providerName;
if(realName == null ||
    !lookup.TryGetValue(realName.Value, out providerName))
    return null;
return providerName;
半窗疏影 2024-11-10 06:22:23

你有了代码,如果你想知道它的效率如何,只需测量它即可。

当然,人们经常担心代码的效率,但其实他们不应该担心。可读性不是更重要吗?这是让你减慢速度的代码吗?

话虽这么说,第一个代码可以稍微快一点,如下所示:

public String FindProviderName(Int32? TrueName)
{
    String providerName = this.Providers
                              .First(p => p.TrueName == TrueName)
                              .Select p.ProviderName);

    return providerName;
}

第二个代码可以通过使用 for 而不是 foreach 来加快速度(如果您的集合类型是 < 但是,

这两种优化很可能不会产生任何可测量的效果。

You have the code, if you want to know how efficient it is, just measure it.

Of course, people quite often worry about efficiency of code, when they shouldn't. Isn't readability more important? Is this the code that slows you down?

That being said, the firs code could be made slightly faster like this:

public String FindProviderName(Int32? TrueName)
{
    String providerName = this.Providers
                              .First(p => p.TrueName == TrueName)
                              .Select p.ProviderName);

    return providerName;
}

And the second one may be made faster by using for instead of foreach (if your collection type is List<T> or an array.

Both those optimizations most likely won't have any measurable effect, though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文