大数据集的ApolloInMemoryCache性能策略（反应）

从Apollo客户端GraphqQL查询中收到的我要调整的应用程序的初始数据集目前非常大。在“大”中，我的意思是数据似乎在缓存中的“数据”键下归一化为大约7,000个条目。有效负载约为1.6MB。如果要保存缓存的数据条目，则将其标准化为大约3MB。我不喜欢初始查询的工作方式，因为我目前正在重新设计其应用程序以在图形上使用游标和过滤，而不是客户端获取大量数据并自行过滤。当前实现无法扩展，因为在其他位置安装此软件时将返回更大的数据集。但是，我正在寻找一种短期解决方案，以便在执行非常大的重新设计任务时使此缓存的构建速度更快。

*更新于2018年7月25日**游标方法不起作用，因为在获取数据的每个页面/光标期间添加了更多条目时，缓存写入性能下降。

真正的问题是，由于该浏览器的行业（医疗保健）用途，我们必须支持IE 11，它非常慢。这很难衡量，但是在Apollo缓存和响应集成代码方面，它比Chrome慢大约8-10倍。Chrome可能需要1-2秒才能在这些速度较慢的虚拟桌面上构建缓存，而IE则需要10-20秒。

因此，我的问题是：是否有任何性能调整可以帮助缓存更快地构建？我已经附上了屏幕截图，以显示瓶颈所在。chrome与IE中相同，但IE中仅慢了一个数量级。我不确定这是IE的缺点，还是某些可怕的疯狂polyfill问题。屏幕截图显示了性能结果中显示的热点。是的，此屏幕截图是React的开发版本，但我们看不到产品中的任何真正明显的性能提升。屏幕截图实际上只是对图形的调用，并且呈现了约260行的最简单的HTML表。渲染阶段可以忽略。在此阶段，似乎有很多排队的事件或“工作”。也许有一种方法可以暂停此操作？铬'

无论如何，任何建议都将不胜感激。

屏幕截图列为：功能| 调用计数| 时间（秒）