blocks|key|2157823|text|更多关于sproutcore的信息..http://ostatic.com/blog/sproutcore-raises-the-bar-for-client-side-programming|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2157824|另一方面，如果您正在寻找并发性，那么node.js就是最佳选择。|2157825|entityMap|0|LINK|mutability|MUTABLE|url|http://ostatic.com/blog/sproutcore-raises-the-bar-for-client-side-programming^0|J|25|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

More on sproutcore here.. <a href="http://ostatic.com/blog/sproutcore-raises-the-bar-for-client-side-programming" rel="nofollow noreferrer">http://ostatic.com/blog/sproutcore-raises-the-bar-for-client-side-programming</a>

If on the other hand you are looking for concurrency then node.js is the way to go.

blocks|key|2157872|text|我想提供的demo不是动态生成的--它是静态数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2157873|很少有系统能够迭代这种大小的实时数据集合。有许多技术，包括流式传输数据集(使用批处理迭代遍历记录)到缓存和ajax部分加载策略。|2157874|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I imagine the demo provided isn't being generated dynamically - it's static data. 

Very few systems would be able to iterate a collection of live data that size. There are a number of techniques including streaming the dataset (using batch iteration through the records) through to caching and ajax partial loading strategies.

blocks|key|597448|text|SproutCore用来在“无限”数据列表中平滑地显示和滚动的技术与数据的来源几乎没有关系，而几乎全部与特殊的SproutCore视图类、SC.CollectionView+(+SC.ListView和SC.GridView的父类)和SC.ScrollView的集成有关；强大的客户端数据存储库类的集合：SC.Store和SC.SparseArray；以及SproutCore运行时和控制器体系结构。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|597449|事实是，您不能简单地呈现一个包含数十万个项目的列表，并期望浏览器不会停止工作。插入到DOM树中的元素太多了，这就是为什么SC.CollectionView被优化为只为列表中当前显示的项生成元素(例如，.如果2000万个项目中只有20个可见，则DOM中只有20个元素)。不过，它甚至比这更好，因为在默认情况下，当项目滚动进和滚动出视图时，少数现有元素会用新的项目信息在适当的位置更新，因此DOM树甚至不会被触动。然而，如果没有SC.ScrollView的集成，这是不可能的，因为它允许集合知道它的可视矩形以及滚动即将发生的时间。|597450|最重要的是，有一个完整的SproutCore运行时体系结构，它用于确保所有的DOM操作都排入队列，以便在显示属性发生变化(例如，.在一个运行循环中切换显示属性50次，只会使用最终值触及DOM一次)。这是影响包括SC.CollectionView在内的所有SproutCore视图的极端性能的一个重要因素。|597451|最后，要使列表真正尖叫，您不能在一个请求中将几百万个项目加载到客户端，甚至不能将它们全部存储在客户端内存中。这就引出了对SC.CollectionView和SproutCore数据存储的另一个优化，即处理稀疏数据。SC.CollectionView永远不会尝试迭代其内容中的每一项，因此它不需要所有存在的数据，只需要显示的数据即可。当我们将数据加载到客户端时，我们将根据需要使用SC.SparseArray一次调入一小部分数据。整个系统的设计非常优雅，当集合视图请求稀疏数组还没有的项时，稀疏数组在后台获取它(或下一页项)。由于使用了绑定和观察器，当新数据传入时，我们可以在适当的位置更新列表，这意味着在数据传入时滚动不会阻塞。|597452|上面的演示非常过时，这里是一个使用了我上面提到的技术的新演示：http://showcase.sproutcore.com/#demos/Big%2520Data+(源代码在这里：https://github.com/sproutcore/demos/tree/master/apps/big_data)。在本演示中，我滚动浏览了50,000个名称，这是我所能生成的全部内容，并将其拆分为500个JSON文件，每个文件包含100个名称，这些文件从服务器远程加载。滚动过100个姓名后，您将看到下100个姓名被调入，并且有一段简短的占位符文本"…“闪现(您看到占位符文本的时间长短取决于您的Internet连接)。|597453|我使用了50,000个名字，但我不认为显示500,000或500万个名字的列表有任何问题。然而，在这种规模下，当您使用SC.Store#unloadRecords引入新数据以降低内存使用量时，您可能还希望对数据进行“取消分页”。|597454|还有一些其他的技术可以使我错过的整个事情成为可能，但这些至少是主要的。|597455|entityMap|0|LINK|mutability|MUTABLE|url|http://showcase.sproutcore.com/#demos/Big%2520Data|1|https://github.com/sproutcore/demos/tree/master/apps/big_data^0|1X|H|2H|B|2T|B|39|D|48|8|4H|E|0|1O|H|5W|D|0|2X|H|0|1O|H|2Z|H|59|E|0|V|1C|0|2G|1P|1|0|1N|M|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1E|8|@$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1M|8|@$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1T|8|@]|D|@$9|1U|A|1V|1|1W]|$9|1X|A|1Y|1|1Z]]|E|$]]|$1|N|3|O|5|6|7|20|8|@$9|21|A|22|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|23|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|24|8|@]|D|@]|E|$]]]|S|$T|$5|U|V|W|E|$X|Y]]|Z|$5|U|V|W|E|$X|10]]]]

The technology that SproutCore uses to display and scroll smoothly through "infinite" lists of data has very little to do with where the data comes from and almost all to do with the integration of special SproutCore view classes, <code>SC.CollectionView</code> (the parent class of <code>SC.ListView</code> and <code>SC.GridView</code>) and <code>SC.ScrollView</code>; the collection of powerful client side datastore classes: <code>SC.Store</code> and <code>SC.SparseArray</code>; and the SproutCore runtime and controller architecture. 

The fact is that you simply cannot render a list of several hundred thousand items in it and expect the browser not to grind to a halt. That is too many elements to insert into the DOM tree and that is why <code>SC.CollectionView</code> is optimized to only generate elements for the currently showing items in the list (ex. if only 20 items are visible out of 20 million, only 20 elements are in the DOM). It gets even better than that though, because by default as items scroll in and out of view, the few existing elements are updated in place with the new item information so that the DOM tree is not even touched. This would not be possible though without the integration of <code>SC.ScrollView</code> that allows the collection to be aware of its visible rect and when a scroll is about to happen.

On top of that, there is the entire SproutCore runtime architecture which is used to ensure that all DOM manipulations are queued up so that you only touch the DOM once per run loop if needed when a display property changes (ex. toggling a display property 50 times in one run loop only touches the DOM once with the final value). This is an important factor in extreme performance that affects all SproutCore views including <code>SC.CollectionView</code>.

Finally, to make the list really scream, you cannot load several million items into the client in one request, nor can you even store them all in client memory. This leads me to another optimization of <code>SC.CollectionView</code> and the SproutCore data store, which is to work with sparse data. <code>SC.CollectionView</code> will never try to iterate over every item in its content, so it doesn't need all the data present, only what is being shown. When we load data into the client, we would use an <code>SC.SparseArray</code> to page in a bit of data at a time as needed. The whole system is very elegantly designed so that when the collection view requests an item that the sparse array doesn't yet have, the sparse array fetches it (or the next page of items) in the background. Because of bindings and observers, when the new data comes in we can update the list in place, which means that the scrolling doesn't block while data is being brought in.

That demo above is very outdated, here is a new one that uses the technologies I mentioned above: <a href="http://showcase.sproutcore.com/#demos/Big%20Data" rel="nofollow">http://showcase.sproutcore.com/#demos/Big%20Data</a> (source is here: <a href="https://github.com/sproutcore/demos/tree/master/apps/big_data" rel="nofollow">https://github.com/sproutcore/demos/tree/master/apps/big_data</a>). In this demo, I scroll through 50,000 names, which is all I could generate and split into 500 JSON files of a 100 names each that are loaded remotely from the server. Once you scroll past 100 names, you will see that the next 100 names are paged in and there is a brief flash of placeholder text "…" (how long you see the placeholder text depends on your Internet connection).

I used 50,000 names, but I don't see any problem showing a list of 500,000 or 5 million names though. However, at that scale you would want to also 'un-page' data as you bring in new data using <code>SC.Store#unloadRecords</code> to keep the memory use down.

There's a few other technologies in play to make this whole thing possible that I've missed, but those are the main ones at least.

I really don't have any substantial code to show here, actually, that's kinda why I am writing: I looked at the SproutCore demo, especially the Collection demo, on <a href="http://demo.sproutcore.com/sample_controls/" rel="nofollow noreferrer">http://demo.sproutcore.com/sample_controls/</a>, and am amazed by its loading 200,000 records to the page so easily. I tried using Rails to provide 200,000 records and in a completely blank HTML page with 
&lt;% @projects.each do |p| %>
 &lt;%= p.title %>
&lt;% end %>
that freezes the browser for seconds on my m1530 laptop with 4gb ram and t7700 256gb ssd.

Yet the sproutcore demo does not freeze and takes less than 3 seconds to load. 

What do you think the one technique they are using to enable this is?

Thanks!

how to handle large dataset like sproutcore

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我真的没有什么实质性的代码可以在这里展示，实际上，这就是为什么我要写:我看了上的SproutCore演示，特别是集合演示，我很惊讶它能如此轻松地将200,000条记录加载到页面。我尝试使用Rails提供200,000条记录，并在一个完全空白的HTML页面中使用<% @projects.each do |p| %> <%...

问如何处理像sproutcore这样的大型数据集
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理像sproutcore这样的大型数据集EN