亚音速和LinqTemplate：为什么这里读取这么慢？
不知道从哪里向亚音速团队提供这些信息，因为他们关闭了论坛，并说使用 stackoverflow，所以我们开始吧。
我一直在努力通过 ORM 实现最大性能。我喜欢 subsonic，在这种情况下，它的批量插入、更新、删除会消除实体框架，但是对于直接简单的读取，EF 以快 5 倍的性能将 subsonic 吹得水泄不通。
我已经剥离了两者，删除了更改跟踪、外部属性、导航属性，一切都归结为 poco。
EF 在大约 4.8 中执行了 1M 行的简单选择，SubSonic Linq 花费了 5 倍...
查看 SQL 探查器，调用略有不同： 实体框架：选择顶部 (1000000) [c].[Id] AS [Id]， [c].[ProjectIDL] AS [ProjectIDL]， [c].[DescriptorIDL] AS [DescriptorIDL]， [c].[FieldIDL] AS [FieldIDL]， [c].[数据] AS [数据]， [c].[OptionId] AS [OptionId] FROM [dbo].[DescriptorFieldValues] AS [c]
SubSonic:SELECT TOP (1000000) [t0].[Data], [t0].[DescriptorIDL], [t0].[FieldIDL], [t0].[Id]、[t0].[OptionId]、[t0].[ProjectIDL] FROM [dbo].[DescriptorFieldValues] AS t0
SQL 探查器正在运行跟踪并在此处显示巨大的持续时间差异。
我在两个查询之前检查了审核登录，它们是相同的...
如果我在 sql management studio 中运行相同的查询，则两个查询都需要 11 秒
查看 subsonic 3.04 源代码，我无法弄清楚我将在哪里进行调整使它与 EF 匹配，但是这里的查询语法真的有那么大的区别吗？还是有一些我不知道的魔法？
感谢您的帮助！
Not sure where to get this info out to the subsonic crew as they took down their forums, and said use stackoverflow, so here we go.
I've been struggling to achieve maximum performance with an ORM. I love subsonic, and its bulk insert, update, delete obliterates Entity Framework in this context, however for straight simple reads, EF blows subsonic out of the water with 5x faster performance.
I've stripped both down, removed change tracking, foreign properties, navigational properties, everything down to poco.
EF executes a simple select of 1M rows in about 4.8, SubSonic Linq is taking 5x that...
looking at SQL profiler the call is slightly different:
Entity Framework: SELECT TOP (1000000)
[c].[Id] AS [Id],
[c].[ProjectIDL] AS [ProjectIDL],
[c].[DescriptorIDL] AS [DescriptorIDL],
[c].[FieldIDL] AS [FieldIDL],
[c].[Data] AS [Data],
[c].[OptionId] AS [OptionId]
FROM [dbo].[DescriptorFieldValues] AS [c]
SubSonic:SELECT TOP (1000000) [t0].[Data], [t0].[DescriptorIDL], [t0].[FieldIDL], [t0].[Id], [t0].[OptionId], [t0].[ProjectIDL]
FROM [dbo].[DescriptorFieldValues] AS t0
SQL profiler is running a trace and showing a massive duration difference here.
I checked the audit login before both queries and they are identical...
If I run the same query in sql management studio it takes 11 seconds for both queries
Looking into the subsonic 3.04 source, I cannot figure out where I would make the adjustment to make it match EF, but is the query syntax here really making that big of a difference, or is there some magic going on I'm not aware of?
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了您的 SubSonic 查询似乎没有选择 ID 字段这一事实之外，这两个 SQL 语句在所有意图和目的上都是相同的。发现这两个查询在 SQL Management Studio 中执行所需的时间相同，这似乎支持了这一点。
这似乎表明 SubSonic 实际上比 EF 需要更长的查询时间。 已知 SubSonic 存在一些性能问题最肯定地解释了这种差异。
不过，实际上，我们需要有关您的确切用法的更多详细信息，才能真正确定为什么此查询对您来说速度较慢的答案。
另外，如果您正在寻找有关 SubSonic 的当前活动和帮助，您应该尝试他们的 Google 网上论坛 。
《SubSonic》的创作者 Rob Conery 已经停止开发它很久了，“SubSonic 团队”还没有发布任何实质性的更新（如果有的话，我认为他们没有发布，但我不完全确定） ）。这是一个您也可以认为“完成”的项目，因为该项目的工作已经停止（出于所有实际目的），但在某种程度上，实际上并不需要更多的工作（它有效）。
顺便说一句，那个页面说 SubSonic 论坛已关闭并转到 StackOverflow - 好吧，这些页面已经一年多（也许是 2 年）没有更新了。
Aside from the fact that your SubSonic query doesn't seem to be selecting the ID field, the two SQL statements are for all intents and purposes identical. Finding that the two queries take the same amount of time to execute in SQL Management Studio seems to support this.
That would seem to indicate that SubSonic does in fact take longer to query than EF. SubSonic is known to have some issues with performance that could most certainly explain this difference.
Really, though, we'd need far more detail on your exact usage to really pin down an answer to why this query is slower for you.
Also, if you are looking for the current activity and help with SubSonic, you should try their Google Group.
The creator of SubSonic, Rob Conery, stopped working on it quite a while ago, and the "SubSonic crew" haven't released any substantial updates (if any at all, I don't think they have but I'm not completely certain). It's a project that you may as well consider "finished" in that work on the project has ceased (for all practical purposes) but in a way more work isn't really needed exactly (it works).
By the way, that page that says the SubSonic forums are shut down and come to StackOverflow - well, those pages haven't been updated at all in over a year, maybe 2.
Rob Corney 指责我们想要了解为什么 SubSonic 比 EF 慢，并告诉我们想要了解为什么 SubSonic 坏了是愚蠢的，我们相信我们的团队已经确定了这些性能问题的几个地方：
我们的团队计划按以下顺序进行以下修改：
在 Extensions/Database.cs ToEnumerable 中一次提取属性信息并将其传递到加载中，这被认为对性能影响最小，但可能会提高内存利用率
修改 ToEnumerable 以对大型数据集的物化进行多线程处理。
希望这能够实现我们的性能需求。
感谢 Jeff V、Ken I 和 QES 的帮助。令人遗憾的是，SubSonic 的创建者 Rob Corney 对 SubSonic 的性能如此持戒态度，而事实上它似乎很容易解决。
〜JT
After getting berated by Rob Corney for wanting to learn why SubSonic is slow in comparison to EF, and told we are stupid for wanting to learn why SubSonic is broke, we believe our team has identified a couple places for these performance issues:
Our team plans to make the following modifications, in the following order:
In Extensions/Database.cs ToEnumerable pull the property infos once and pass them into load, this is believed to have mininmal performance impact, but likely a decent memory utilization impact.
Modify ToEnumerable to multithread the materialization for large datasets.
Hopefully this should bring our performance needs to fruition.
Thank you to Jeff V, Ken I, and QES for their help. It's sad to see the creator of SubSonic Rob Corney so defensive about SubSonic's performance, when it appears to be fairly easy to solve.
~ JT
Subsonic 3 之所以如此缓慢，是因为它在运行之前需要一次又一次地编译去sql server并询问结果。
这个编译发生在 linq 部分。
例如，像
"Select * FROM Products WHERE ProductID > 100"这样的简单静态命令，在 subsonic 3 中输入Products.Find(x => (x.ProductID > 100)首先需要很多时间来转换为字符串命令，我的意思是很长的时间，这是 subsonic 如此慢的主要原因，这就是 subsonic 3
在 linq 中毫无价值 的原因。 .Compile 函数编译一次并将其记住在内存中，但是对于我和我的标准来说也很慢。
现在回到亚音速 2，这是一个非常好的主意，但显然它们内部仍然需要大量优化。想太多的速度。无论如何，通过一些优化，subsonic 2 可以超级快，接近
我一年前的测试：
基准 Linq2SQL、Subsonic2、Subsonic3 - 任何其他想法让他们更快？
我的想法是回到亚音速2，让它更好更快，然后放弃亚音速3。我感谢他们的亚音速2和亚音速3，但在版本3中他们失败了，它好吧，这些年我做了太多的程序，并没有全部使用。没什么大不了的。
Subsonic 3 is so slow because its need to compile again and again and again the same thinks before its go to sql server and ask for results.
And this compile is happens on the linq part.
For example a simple static command like
"Select * FROM Products WHERE ProductID > 100"that typed in subsonic 3 asProducts.Find(x => (x.ProductID > 100)needs first a lot of time to converted to string command, and I mean a very long time.This is the main reason why subsonic is so slow, and thats why subsonic 3 is worthless.
In linq the trick is the CompiledQuery.Compile function that compile it one time and remember it in memory. How ever for me and my standards is slow too.
Now back to subsonic 2, this is a really nice idea, but still need a lot of optimization inside. Apparently they not think too much the speed. Anyway with some optimization subsonic 2 can be super fast, near the simple ado commands.
My tests a year ago:
Benchmark Linq2SQL, Subsonic2, Subsonic3 - Any other ideas to make them faster?
My idea is to go back to subsonic 2 and make it better and speedy, and drop the subsonic 3. I thank them for both subsonic 2 and 3, but in the version 3 they fail, its ok, I have made too many programs all that years, and not all of them used. Is not big deal.