今天处理了一个奇葩的 IE 性能问题，可能我以前低估了 IE 的性能多差

[murmur]

需求很简单，一个 50 行左右的简单表格，每行有三四个文本框可以编辑，做了表列锁定，用的饿了么 UI，用户说 IE11 卡，按理说都是这几年买的电脑，win10 也装了，IE11 性能怎么也不可能这么差

分析过程略，直接给结果，我们来做题

每行 4 个文本框，50 行，那么一页就有 200 个文本框

因为饿了么的列锁定是 2 个重叠表格实现的，也就是同样的文本框渲染了 2 次，所以一页现在就有 400 个文本框

关键来了，IE11 下，饿了么的 input 会计算自己的高度（我们知道，老一点的浏览器在获取计算长宽这样的属性时会把所有缓存的东西算一下得到正确值），这样一次 patch 需要 20-30ms

所以这 400 个文本框的总耗时会超过 10 秒，虽然性能分析模式慢一些，但是实际上也要 6 秒以上了

[ke1vin]

说得跟 chrome 就不会卡一样，没记错的话 Element UI 的 input 进来就会执行一个触发重绘的函数

[charlie21]

大概这就是大佬吧

[aaronlam]

之前做过一个公司的内部系统也是表格，也是 Element-UI，但是我的表格有 10-20 个列，并且有编辑模式，编辑模式下有些列还需要转为 Input 和 Select 组件。然后以至于在 IE 下奇卡无比，但是在 Chrome 和 Firefox 就表现良好。后面把表格折腾成了虚拟滚动才算是解决卡顿问题，但是体验感觉就没有原来的真实滚动来的好。IE 的性能真的不能直视。。

[secondwtq]

Safari 就不会有这个问题（

[PopRain]

以前用 IE 打开谷歌的在线电子表格感觉不出性能问题，这个列更多

[jorneyr]

@PopRain 这么看来，根源在 Element Ui 上

[wdhwg001]

没有苹果的 WebKit 项目的话，那就是你现在能用的最好的浏览器了。

[murmur]

@jorneyr 是的，他们再 issue 里明确表态用两个表格重叠实现列固定是设计，不属于 bug，虽然我也想不到更好的本法

[murmur]

@wdhwg001 微软的 edge 虽然不稳定性能也不差，firefox 和 opera 我记得以前也是自研引擎

[ragnaroks]

做法没问题,问题出在一次计算居然要 20ms 以上,1ms 都足够大型游戏刷写十几次

[loading]

从 ie5.5 走过来的表示:习惯了。

[loading]

现在更快的计算机，代码性能问题很容易被掩盖，现在的手机性能能登多少次月了，如果让现在的人去写，可能都不能离地。

[eitomomobaohua]

@murmur Edge 是 Chrome 内核啊，Chrome 也是 Webkit 的分支

[no1xsyzy]

@ragnaroks 你说的这个大型游戏，它现场排版吗？

[no1xsyzy]

@eitomomobaohua 老 Edge 不是 Chromium 内核

[xiyuesaves]

@eitomomobaohua edge 转成 Chromium 内核也只是今年年初的事情啊,在此之前用的是自研 EdgeHTML

[idealhs]

@wdhwg001 现代内核有很多，不要哪里都吹果

[wdhwg001]

@murmur 但是它们之中只有火狐有在推行标准，最大的贡献就是逼着 IE 实现了完整的 CSS3 支持，但是直到 WebKit 普及之前，JScript 和 ActiveX 都是浏览器的金标准。

[wdhwg001]

@idealhs 就连 IE 11 都是果时代的结果了，你看 IE 11 里有多少对-webkit-的支持就知道了。

[ruanimal]

@wdhwg001 WebKit 的 HTML 及 JavaScript 代码源自 KDE 的 KHTML 及 KJS 库的一个分支, 别把苹果抬那么高