blocks|key|33066|text|您可以使用不同的技术来加载您的所有项目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|33067|您可以创建自己的逻辑，以便在用户滚动ListView时加载部分数据(我猜您正在使用它)。|33068|幸运的是，UWP有一种简单的方法来完成这项技术。增量加载请参阅文档和示例|33069|https://msdn.microsoft.com/library/windows/apps/Hh701916|offset|length|33070|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1K|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@$H|U|I|V|1|W]]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|G]]]]

you can use a different technique to load all your items.

you can create your own logic to load parts of the data while the user is scrolling the ListView( I guess you are using it) .

fortunately UWP a easy way to do this technique.
Incremental loading
please see the documentation and example 

<a href="https://msdn.microsoft.com/library/windows/apps/Hh701916" rel="nofollow">https://msdn.microsoft.com/library/windows/apps/Hh701916</a>

blocks|key|32546|text|大多数答案遵循加载较少数据的常识，但在某些情况下，例如在这里，您绝对肯定地必须加载大量实体。那么我们如何做到这一点呢？|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|32547|性能不佳的原因|32548|这个操作花这么长时间是不可避免的吗？嗯，不是的。我们只从磁盘加载了一兆字节的数据，性能低下的原因是数据被拆分到40,000个微小实体上。数据库可以处理这一点，但是实体框架似乎很难设置所有这些实体，更改跟踪等。如果我们不打算修改数据，我们可以做很多事情。|32549|我试了三件事|32550|原语|32551|只加载一个属性，然后你就会得到一个原语列表。|32552|List<double>+dataPoints+=++_db.DataPoints.Select(dp+=>+dp.Value).ToList();|code-block|syntax|javascript|32553|这绕过了通常由实体框架执行的所有实体创建。此查询耗时0.4秒，而原始查询为18秒。我们讨论的是45+(!)倍的改进。|32554|匿名类型|32555|当然，大多数时候我们需要的不仅仅是一个基元数组，我们可以在LINQ查询中创建新的对象。实体框架不会创建它通常会创建的实体，并且操作运行得更快。为了方便起见，我们可以使用匿名对象。|32556|var+query+=+db.DataPoints.Select(dp+=>+new+{Guid+ID+=+dp.sensorID,+DateTimeOffset+Timestamp+=+dp.TimeStamp,+double+Value+=+dp.Value});|32557|此操作需要1.2秒，而通常检索相同数量的数据需要18秒。|32558|元组|32559|我发现在我的例子中，使用元组而不是匿名类型略微提高了性能，以下查询的执行速度大约快了30%25：|32560|var+query+=+db.DataPoints.Select(dp+=>+Tuple.Create(dp.sensorID,+dp.TimeStamp,+dp.Value));|32561|其他方式|32562|32563|您不能在LinQ查询中使用结构，因此这不是一个选项|ordered-list-item|32564|在许多情况下，您可以将许多记录组合在一起，以减少与检索许多单独记录相关的开销。通过检索较少的较大记录，您可以提高性能。例如，在我的使用案例中，我有一些每5分钟、每周7天、每天24小时测量一次的测量结果，目前我将它们单独存储，这很愚蠢。没有人会查询不到一天的时间。我计划在我做出改变时更新这篇文章，看看性能是如何变化的。|32565|有些人推荐使用面向对象的数据库或微对象关系映射。我也从来没有用过，所以我无可奉告。|32566|32567|entityMap^0|11|M|0|5|2|0|0|3I|0|0|6|0|0|2|0|0|M|0|0|0|1M|0|0|4|0|0|2H|0|0|0|S|0|0|2|0|0|1A|0|0|0|4|0|0|0|P|0|0|4F|0|0|15|0|0^^$0|@$1|2|3|4|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1T|8|@$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1W|8|@$9|1X|A|1Y|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1Z|8|@$9|20|A|21|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|22|8|@$9|23|A|24|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|R|7|25|8|@]|D|@]|E|$S|T]]|$1|U|3|V|5|6|7|26|8|@$9|27|A|28|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|29|8|@$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|2C|8|@$9|2D|A|2E|B|C]]|D|@]|E|$]]|$1|10|3|11|5|R|7|2F|8|@]|D|@]|E|$S|T]]|$1|12|3|13|5|6|7|2G|8|@$9|2H|A|2I|B|C]]|D|@]|E|$]]|$1|14|3|15|5|6|7|2J|8|@$9|2K|A|2L|B|C]]|D|@]|E|$]]|$1|16|3|17|5|6|7|2M|8|@$9|2N|A|2O|B|C]]|D|@]|E|$]]|$1|18|3|19|5|R|7|2P|8|@]|D|@]|E|$S|T]]|$1|1A|3|1B|5|6|7|2Q|8|@$9|2R|A|2S|B|C]]|D|@]|E|$]]|$1|1C|3|-4|5|6|7|2T|8|@]|D|@]|E|$]]|$1|1D|3|1E|5|1F|7|2U|8|@$9|2V|A|2W|B|C]]|D|@]|E|$]]|$1|1G|3|1H|5|1F|7|2X|8|@$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|1I|3|1J|5|1F|7|30|8|@$9|31|A|32|B|C]]|D|@]|E|$]]|$1|1K|3|-4|5|6|7|33|8|@]|D|@]|E|$]]|$1|1L|3|-4|5|6|7|34|8|@]|D|@]|E|$]]]|1M|$]]

Most answers follow the common wisdom of loading less data, but in some circumstances such as here you Absolutely Positively Must load a lot of entities. So how do we do that? 

Cause of poor performance

Is it unavoidable for this operation to take this long? 
Well, its not. We are loading just a megabyte of data from disk, the cause of poor performance is that the data is split across 40,000 tiny entities. The database can handle that, but the entity framework seem to struggle setting up all those entities, change tracking, etc. If we do not intend to modify the data, there is a lot we can do. 

<h2>I tried three things</h2>

<h3>Primitives</h3>

Load just one property, then you get a list of primitives. 

<pre><code>List&lt;double&gt; dataPoints = _db.DataPoints.Select(dp =&gt; dp.Value).ToList();
</code></pre>

This bypasses all of entity creation normally performed by entity framework. This query took 0.4 seconds, compared to 18 seconds for the original query. We are talking 45 (!) times improvement. 

<h3>Anonymous types</h3>

Of-course most of the time we need more than just an array of primitives
We can create new objects right inside the LINQ query. Entity framework won't create the entities it normally would, and the operation runs much faster. We can use anonymous objects for convenience. 

<pre><code>var query = db.DataPoints.Select(dp =&gt; new {Guid ID = dp.sensorID, DateTimeOffset Timestamp = dp.TimeStamp, double Value = dp.Value});
</code></pre>

This operations takes 1.2 seconds compared to 18 seconds for normally retrieving the same amount of data. 

<h3>Tuples</h3>

I found that in my case using Tuples instead of anonymous types improves performance a little, the following query executed roughly 30% faster:

<pre><code>var query = db.DataPoints.Select(dp =&gt; Tuple.Create(dp.sensorID, dp.TimeStamp, dp.Value));
</code></pre>

<h3>Other ways</h3>

<ol>
<li>You cannot use structures inside LinQ queries, so that's not an
option</li>
<li>In many cases you can combine many records together to reduce
overhead associated with retrieving many individual records. By
retrieving fewer larger records you could improve performance. For
instance in my usecase I've got some measurements that are being
taken every 5 minutes, 24/7. At the moment I am storing them
individually, and that's silly. Nobody will ever query less than a
day worth of them. I plan to update this post when I make the change
and find out how performance changed. </li>
<li>Some recommend using an object oriented DB or micro ORM. I have
never used either, so I can't comment.</li>
</ol>

blocks|key|32591|text|对2600万条记录(1个datetime，1个double，1个int)进行性能测试，EF+Core+3.1.5：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|32592|接受答案中建议的|32593|匿名类型或元组=大约20秒，1.3+20|unordered-list-item|32594|32595|32596|结构=大约15秒，0.8+15内存|32597|32598|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|P|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|S|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|M|$]]

Performance test on 26 million records (1 datetime, 1 double, 1 int), EF Core 3.1.5:
<ul>
<li>Anonymous types or tuples as suggested in the accepted answer = About
20 sec, 1.3GB RAM
</li>
<li>Struct = About 15 sec, 0.8GB RAM
</li>
</ul>

I am reading 40,000 small objects / rows from SQLite with EF core, and it's taking 18 seconds, which is too long for my UWP app. 
When this happens CPU usage on a single core reaches 100%, but the disk reading speed is circa 1%. 

<pre><code>var dataPoints = _db.DataPoints.AsNoTracking().ToArray();
</code></pre>

Without <code>AsNoTracking()</code> the time taken is even longer. 

<code>DataPoint</code> is a small POCO with a few primitive properties. Total amount of data I am loading is 4.5 MB. 

<pre><code> public class DataPointDto
 {
 [Key]
 public ulong Id { get; set; }

 [Required]
 public DateTimeOffset TimeStamp { get; set; }

 [Required]
 public bool trueTime { get; set; }

 [Required]
 public double Value { get; set; }
 }
</code></pre>

Question: Is there a better way of loading this many objects, or am I stuck with this level of performance? 

Fun fact: x86 takes 11 seconds, x64 takes 18. 'Optimise code' shaves off a second. Using <code>Async</code> pushes execution time to 30 seconds.

Reading thousands of objects with EF Core FAST

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我从EF内核的SQLite中读取了40,000个小对象/行，耗时18秒，这对于我的UWP应用程序来说太长了。当发生这种情况时，单核上的CPU使用率达到100%，但磁盘读取速度约为1%。var dataPoints =  _db.DataPoints.AsNoTracking().ToArray();如果没有AsNoTr...

问使用EF Core FAST读取数千个对象
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用EF Core FAST读取数千个对象EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用EF Core FAST读取数千个对象
EN