我正在使用Ember JS 2.3.0,Ember Data 2.3.3和jQuery 2.1.4,当我尝试从带有HTML表格组件的页面转换时,我遇到了一个问题。表组件使用此Ember Data调用中的数据进行填充:
this.store.query('log', {filter: {
created_at_from: moment().subtract(1, 'month').format('DD/MM/YYYY'),
created_at_to: moment().format('DD/MM/YYYY'),
object: 'IsoApplication'
}})
已经查看了开发人员工具“时间轴”和“网络”标签的正在及时解决。它没有附加特殊的jQuery事件等,它只是一个用Ember动态创建的纯HTML表。
但是,当单击“链接到”帮助程序时,它会从包含组件的页面转移出来,在目标页面呈现之前会有10秒的延迟。在此期间似乎没有任何事情发生,并且使用开发人员工具“时间轴”并向下钻取它似乎在调用“removeFromListeners”函数时发生延迟(参见附件时间轴截图)。此时没有发生异步事件,因此没有加载器出现,但似乎拆除表是问题,因为如果我从模板中删除表组件,问题就会消失。没有表格组件,页面几乎立即过渡。
我附上时间轴截图,看看是否有人可以帮助查明此问题的可能原因。 任何建议都会受到欢迎。
感谢。
答案 0 :(得分:0)
好的,在显着减少表格中的行数后,我发现问题消失了。 @runspired提供了一个详细且非常有用的描述我的问题发生的原因,我在下面发布这些描述以通知可能有类似问题的其他人:
这里有很多事情
我就此进行了一些讨论(包括关于Ember Weekend的两个播客(第38和39集))
我希望我记录下我的chicago-ember谈话,但我没有
但基本上,归结为三个原因,为什么这很慢
并且实际上没有一个是因为“dom很慢”,这个论点掩盖了事情的真相
1。)不渲染宇宙,渲染场景
最简单的比喻是你能想到的任何视频游戏,特别是你可以快速“转动”相机视图的游戏
该枢轴很像滚动
你真的只想呈现当前可见的内容,并准备更接近相机视图的内容
但是准备远远超出视野的内容是没有意义的
这是每个原生SDK和游戏SDK都已经出现的教训,但是尚未实现JS框架
当人们说DOM很慢时,真的是因为他们试图渲染的东西远远超过他们应该的
2.。)是大多数浏览器中的错误
为DOM分配的内存始终由分配它的选项卡保留
此分配会持续超出页面的生命周期
这是一个真正的泄漏,希望Chrome等很快就会解决
或者基本上,DOM的分配堆大小只能增长
你可以重用已分配的内存,但你不能缩小它
这意味着如果你生成了大量的DOM节点,即使你把它们拆掉,那么这个标签的内存开销也很高
会导致其他区域出现性能问题,因为可用于JS分配的内存较少等。
这个问题在移动设备,特别是Android上比在桌面上更大。但它也会影响桌面。
与1和2相关的东西
在浏览器启动之前可以渲染多少个DOM节点有明确的限制
我发现限制为大约40k DOM节点,从旧版Android设备上的低至20k变为> Safari上的100k
但40k似乎是一个限制,如果作为目标保持适用于所有平台
如果您有700-2000个表行,并且每行可能有3个TD,并且每个TD只有一个链接或跨度或其他元素,那么您有一些文本
6,300 - 18,000个节点
或者基本上,您使用该设置处理最大预算的一半
就像行的内容
一样所以7002 - 20,002个节点计数行
并且每行9个节点可能是一个非常低的估计值
如果我们加倍
你超过了那个
和18个节点听起来更可能
3.)GC事件阻止世界
[9点28] 即使选项卡分配的内存保留
分配IS清理
(因此可以在以后重复使用更多DOM)(已编辑)
所以你要一次性释放最大DOM大小(可能更大)的内存
浏览器清理
的内容很多在这段时间内,很多阵列和阵列观察者也可能被拆除。
@runspired也是 https://github.com/runspired/smoke-and-mirrors的作者,该项目是:
专注于通过为高性能列表和细分渲染提供组件和基元来提高高压力情况下的初始和重新渲染性能,以匹配核心信念:不渲染Universe,渲染场景。