0

分析我的应用程序时，我发现了一个令人不快的事实，即键入 Upadte<>（和 Query<>）构建器会在每个请求上评估 lambda 表达式，这会消耗大量 CPU。您将获得几个百分比的 CPU，从漂亮和现代类型的 UpdateBuilder<> 切换为：

var u = Update<MyPerson>.Inc(e => e.Age, Age);

到旧的好的静态字符串：

var u = Update.Inc("Age", Age);

QueryBuilder<> 也存在同样的问题，它还在每个请求上评估表达式，并且白白浪费宝贵的 CPU 资源。

官方LINQ 驱动程序页面指出：

C# 编译器无论如何都会在内部将使用查询语法编写的所有查询转换为 lambda 语法，因此选择任何一种样式都没有性能优势或损失。

是的，如果您在两种 LINQ 语法之间进行选择，这是正确的。但是使用和不使用 LINQ 语法之间存在巨大的性能差异。开销取决于您的客户执行查询的频率。就我而言，差异超过30％！

我想知道有什么方法可以同时获得漂亮的类型化语法和性能吗？

就我们显然需要将动态参数传递给每个请求而言，构建器结果的简单缓存并不是一个答案。我们需要找到“预编译”CPU 昂贵部分（关于 lambda 表达式评估）但保留动态参数（例如数组索引）的方法。

4

1 回答 1

0

您引用的段落：

C# 编译器无论如何都会在内部将使用查询语法编写的所有查询转换为 lambda 语法，因此选择任何一种样式都没有性能优势或损失。

指可用于编写 LINQ 查询的两种语法。

var query =
    from e in collection.AsQueryable<Employee>()
    where e.FirstName == "John"
    select e;

或者

var query =
    collection.AsQueryable<Employee>()
    .Where(e => e.FirstName == "John");

这并不意味着 LINQ 查询通常没有开销。所有 LINQ 查询都必须在运行时转换为等效的 MongoDB 查询，并且该过程需要一定量的 CPU 时间。

我们确实希望将来尽可能减少这种开销，但请记住，这种开销只发生在客户端，不会影响服务器。

于 2013-05-09T20:26:20.383 回答