linq-to-sql - 如何优化统计计数顺序以及为何如此缓慢

Question

简介:我花了一整天的时间寻找为什么我的处理操作如此缓慢。它在低数据上真的很慢。我检查了 sql views 、 procedures 和 linq 逻辑——它们都工作得很好。但后来我看到这件小事需要很长时间才能处理。

member X.CountStatistics()= 
    linq.TrueIncidents
    |> PSeq.groupBy (fun v -> v.Name)
    |> PSeq.map (fun (k, vs) -> k, PSeq.length vs)
    |> Array.ofSeq

它只是计算分组的值，但它花费了多少时间! easy table 大约 10 秒，

肯定有什么愤怒的递归但我看不到...

如何使此操作“快一点”或将其重新编码为 linq-to-sql？

Answer 1

如果我理解正确的话，TrueIncidents 是数据库中的一个表，您将把全部内容拉入客户端应用程序以进行一些分组和计数。如果 TrueIncidents 是一个大表，那么这个操作总是会很慢，因为你要移动大量数据。执行此操作的“正确”方法是在数据库上执行此操作，如您建议使用 linq to SQL，或如 Tomas 建议使用存储过程。

关于 PSeq，我认为内联不会产生太大影响。并行化有开销，为了分摊此开销，列表需要相对较大，并且您对列表中的每个项目执行的操作需要很重要。如果您对每个项目执行的操作非常昂贵，那么对于一个小列表来说，并行化可能是值得的，但反过来似乎也是如此；即使列表非常大，并行化一个小操作也不值得开销。因此，这种情况下的问题是您对列表中的每一项执行的操作太小，因此并行化的成本总是会使操作变慢。要看到这一点，请考虑以下 C# 程序，如果我们对包含 1000 万个项目的列表执行简单的添加，您会看到并行版本总是运行缓慢(好吧，在我目前正在使用的机器上，它有两个内核，我想在具有更多内核的机器上结果可能会有所不同)。

    static void Main(string[] args)
    {
        var list = new List<int>();
        for (int i = 0; i < 10000000; i++)
        {
            list.Add(i);
        }

        var stopwatch = new Stopwatch();
        stopwatch.Start();
        var res1 = list.Select(x => x + 1);
        foreach (var i in res1)
        {

        }
        stopwatch.Stop();
        Console.WriteLine(stopwatch.Elapsed);
        // 00:00:00.1950918 sec on my machine

        stopwatch.Start();
        var res2 = list.Select(x => x + 1).AsParallel();
        foreach (var i in res2)
        {

        }
        stopwatch.Stop();
        Console.WriteLine(stopwatch.Elapsed);
        // 00:00:00.3748103 sec on my machine
    }