这是一个创建于 2364 天前的主题，其中的信息可能已经有所发展或是发生改变。
各种轮子都喜欢放自己的各种性能指标，但是实际工作中有真的遇到性能瓶颈吗？
长列表会遇到？
 |
1
Mrun 2018-06-11 10:13:06 +08:00
前端对性能要求的场景在实际项目中，见的少。但是代码不就追求这样么
|
 |
2
chairuosen 2018-06-11 10:16:31 +08:00
那是你没写过复杂项目。。。
|
 |
3
murmur 2018-06-11 10:17:50 +08:00
自从各种 mvvm 开始用性能就已经扔一边去了
正常的前端应用还主要在渲染上 少刷新 dom 少放东西就是王道 包括大数据图表都可以通过抽点解决问题 大列表也可以假拖动 真的出性能问题 游戏的话都上引擎做 app 了 可能视频类带特效弹幕是最容易出性能问题吧 |
 |
4
vevlins OP @chairuosen 所以复杂到有性能瓶颈的项目都是什么样的
|
 |
5
dorentus 2018-06-11 13:32:09 +08:00 via iPhone
话说 Google 为了解决 Gmail 的性能瓶颈，搞出了 v8 …
|
 |
6
xmadi 2018-06-11 13:35:27 +08:00 via iPhone
遇不到
|
 |
7
feverzsj 2018-06-11 13:42:42 +08:00
追求性能的不会用框架，特别是 mvvm，完全和性能背道而驰的设计理念
|
 |
8
geelaw 2018-06-11 13:49:17 +08:00
@dorentus #5 这个说法的根据是啥？从逻辑思考这个想法不是很站得住脚，即使 Google 自己的 JavaScript 引擎解决了 Gmail 的性能问题，如果 Gmail 自己不改善代码，它在其他的浏览器上的性能也没有保障——但是 Gmail 网页版本来就是要让所有的人都能轻松访问 Gmail，如果限制在 Google 的浏览器上，何不推出 Google 自己的客户端来访问（反正，都是 Google 的软件，不差这一个）？
|
 |
9
luoway 2018-06-11 14:03:20 +08:00  2
@feverzsj mvvm 和性能背道而驰是因为频繁操作 DOM，很多 mvvm 框架都优化过其操作 DOM 的频次和范围，并不是主要的性能问题。
图表数据可视化方面的需求是性能重灾区，而图表本身的复杂度也导致许多中小公司开发人员依赖前端框架，那么框架性能问题就有意义了。 |
 |
10
LeungJZ 2018-06-11 14:18:45 +08:00
当遇上超大数据量的滚动 table，左滚右滚的那种。
当遇上大数据量的图表展示，还特么的五彩斑斓还会动的那种。 当遇上 $(xxx).css(); $(xxx).html(); $(xxx).data(xx, yyyy); $(xxx).on(click, func1); $(xxx).on(click, func2); 打死不缓存系列这种。 |
|
11
murmur 2018-06-11 14:29:39 +08:00
@luoway batch insert 了解下 模板渲染插入一气呵成，但是 mvvm 你每个节点都要绑定又蜕化成一个一个插入的年代
|
 |
12
whypool 2018-06-11 15:37:32 +08:00
除了吹没什么卵用
还有说操作 DOM 是浪费渲染时间开销大什么的，来来来，你说一个不操作 DOM 的办法 还有说 JQ 操作 DOM 性能差，那也只能呵呵了，性能差换电脑啊 还有说渲染大数据列表慢，这个慢相对于服务器响应和网络传输，基本忽略不计，是微服务查询发送 10w 条数据慢还是渲染 10w 个 dom 慢心里没点 B 数么 还有说用 mvvm 操作数据绑定 dom 快，什么虚拟 dom 缓存什么的，缓存确实可以提高一下效率，但是，你把 JS 执行的时间和消耗的内存算上去，和原生操作 dom 对比一下，谁快谁慢还不一定呢 前端谈性能是没啥意义的，因为可以从设计层面规避性能问题，比如渲染 1000w 列表，而且很多东西都不能控制，比如 dom 的渲染层级，浏览器的缓存等，虽然很多大佬甚至各种框架都在谈渲染效率，但那也只是作为一个参数看看就行，不止前端，包括所有客户端的执行效率都是和配置相关，代码提升效率只是次要的，虽然有黑科技提高效率，但是依然不能把 1FPS 的吃鸡提升到 60FPS |
 |
15
Foolt 2018-06-11 15:45:38 +08:00
框架渲染效率提高，最大的受益者不是用户，而是前端开发，渲染效率提高了意味着你那坨屎一样的代码不用专门优化速度也不会太慢。
|
 |
16
autoxbc 2018-06-11 15:52:55 +08:00
其实大家说来说去都不是重点，我来说点关键的：浪费的是用户的电和时间，所以开发者和公司不在乎
|
 |
19
371657110 2018-06-11 16:09:58 +08:00
卡就换电脑啊
|
 |
20
learnshare 2018-06-11 16:24:28 +08:00
对实现需求和开发效率的要求比性能高太多了
|
 |
22
inflationaaron 2018-06-12 02:55:09 +08:00 via iPad
牺牲运行效率换开发效率不是所有编程技术的发展么？付出一点运行效率用 Web 跨平台我觉得是个很值得的 trade-off。框架再怎么优化都是有上限的，追求的其实是让一般的程序员写出比自己手写稍微强一点的代码就行了。
|
Select Language