聊聊 computed 影响性能的场景
大家好，我是若川。持续组织了8个月源码共读活动，感兴趣的可以点此加我微信 ruochuan12 参与，每周大家一起学习200行左右的源码，共同进步。同时极力推荐订阅我写的《学习源码整体架构系列》 包含20余篇源码文章。历史面试系列
前言
在 Vue 中，computed 是一个非常好用的 API，用于处理派生状态，又叫“计算属性”。网上将其用于性能优化的场景比比皆是。
但它也有严重影响性能的一面，本文主要是聊聊这种场景。
聊之前，我们先看看它为什么能够做到性能优化。
computed 的两个特点
缓存结果：只有依赖项变化的时候才会重新计算，否则复用上一次计算的结果。
惰性求值：只有在真正读取它的 value 时，才会进行计算求值。
缓存结果
const todos = reactive([{ title: '点赞', done: true},{ title: '关注', done: false }
])const openTodos = computed(() => todos.filter(todo => !todo.done)
)在上图的例子中，只要 todos 不变，多次使用 openTodos 将返回相同的值，不会重新计算。
当 todos 变化时，openTodos 会被标记为 dirty，下次取值时才会进行重新计算。
这点对计算量开销较大的场景非常有用，确保了只有在必要时才会重新计算。
惰性求值
只有在使用 computed 时，它才会进行计算。如果一个计算属性，计算开销非常非常大，但它没有被任何地方使用，也不会进行求值。
computed 提升性能的场景
如上所说，computed 的延迟计算通常是一件好事：它确保了必要时才会进行计算。
下面是一个简单的 Todo 例子，简单说明一下：
有一个 todos 列表
showList用于控制是否展示列表openTodos是计算未完成 todos 列表的计算属性，依赖 todoshasOpenTodos是计算是否有未完成 todos的计算属性，依赖 openTodos
<template><button @click="showList = !showList">点击展示/隐藏</button><template v-if="showList"><template v-if="hasOpenTodos"><h2>{{ openTodos.length }} Todos:</h2> <ul><li v-for="todo in openTodos">{{ todo.title }}</li></ul></template><span v-else>没有任何 Todo</span><input type="text" v-model="newTodo"><button type="button" v-on:click="addTodo">添加 Todo</button></template>
</template><script setup>
const showList = ref(false)const todos = reactive([{ title: '点赞', done: true},{ title: '关注', done: false }
])
const openTodos = computed(() => todos.filter(todo => !todo.done)
)
const hasOpenTodos = computed(() => !!openTodos.value.length
)const newTodo = ref('')
function addTodo() {todos.push({title: newTodo.valuedone: false,})
}
</script>因为 showList 最初是 false，所以模板中不会读取 openTodos，不会产生计算。并且无论是一开始还是添加了新的 todo。只有在 showList 设置为 true 之后，模板中才会读取 openTodos，这才会触发相应的计算。
这对于开销大的计算属性来说，是有很大好处的。
computed 影响性能的场景
惰性求值也会带来一个缺点：计算属性的返回结果，只有在对它进行计算后才会知道。
听起来可能比较难以理解，同样用一个例子来说明：
有一个 list 列表
一个增加 count 的按钮
一旦 count 超过 100（
isOver100），就反向展示 list
当然这里反向展示 list计算量并不大。我们将它想象成一次开销很大的计算
<template><button @click="increase">添加计数</button><h3>列表</h3><ul><li v-for="item in sortedList">{{ item }}</li></ul><>
</template><script setup>
import { ref, reactive, computed, onUpdated } from 'vue'const list = reactive([1,2,3,4,5])const count = ref(0)
function increase() {count.value++
}const isOver100 = computed(() => count.value > 100)const sortedList = computed(() => {// 这里比较简单，可以将它想象成开销大的计算return isOver100.value ? [...list].reverse() : [...list]
})onUpdated(() => {// 组件重新渲染时触发console.log('count is', count.value)console.log('component re-rendered!')
})
</script>预期情况：
当我们点击 1-100 次时，因为 count 小于 100，list 不会反向展示，组件不会重新渲染
当点击第 101 次时， list 才会反向展示，组件这时候才重新渲染
因此，预期总计重新渲染 1 次。
但运行结果告诉我们，组件会重新渲染 101 次！！
让我们一步一步来看发生了什么。
依赖关系如图：
点击按钮，计数增加。由于模板中没有使用 count，理论上不会重新渲染。
但 count 改变后，依赖 count 的计算属性
isOver100被标记为dirty，在下次使用时需要重新计算，并告知了它的订阅者。因为 sortedList 依赖 isOver100，收到 isOver100 的通知后，它也被标记为
dirty，在下次使用时需要重新计算，并告知了它的订阅者。最终模板中使用了 sortedList，所以收到 sortedList 的更新通知后，组件重新渲染了。
重新渲染时，计算 sortedList，接着计算 isOver100，但现在由于 count 不到 100，isOver100 仍然返回 false。
最终 sortedList 计算结果与原来一致，重新渲染后 DOM 无任何改变，但是我们却运行了多次大开销的 sortedList 计算！
简单来说：因为 count 变了，所以 isOver100 “觉得”自己变了，需要重新算（但其实没有），就让依赖它的 sortedList 重新计算了。
根本原因就是 isOver100，它是一个频繁计算且计算非常简单的 computed，多次计算返回值也与之前相同（都为 false）。它只发挥了 computed 状态派生的作用。
但在计算开销大的 sortedList 中，依赖了廉价的 isOver100，因为 computed 是惰性求值的，isOver100 的计算结果只能在渲染时重新计算才会知道，所以 sortedList 也只能在渲染时等待它的计算结果再重新计算，哪怕最终结果一致。导致触发了不必要的重新渲染，用的不好会严重影响性能。
所以影响性能的 computed，通常都有这样的特征：
一个计算简单的 computed，频繁触发计算，并且返回值通常变化不大，比如上面的
boolean类型另一个计算开销大的 computed，依赖这个廉价的 computed
如何解决
我们发现根因是由于 computed 的惰性求值，让 isOver100 "觉得"自己变了，需要重新计算，导致了这一系列的连锁反应。但因为它的计算是廉价的，频繁计算也不会影响性能。
有没有办法不要 computed 的延迟计算呢？在 isOver100 "觉得"自己变了的时候马上就能知道是不是真的变了。在发现自己其实没变后，不再通知订阅者，也就没有了后续的重新渲染。
我们可以将它的计算提前，在依赖变化时就立刻计算得到结果。
设计一种立刻求值的 eagerComputed：
Vue 的响应式系统为我们提供了构建自定义 computed 所必要的工具。手动点赞
聊聊 computed 影响性能的场景相关推荐
- 《vSphere性能设计：性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.2.2 内存...
本节书摘来华章计算机<vSphere性能设计:性能密集场景下CPU.内存.存储及网络的最佳设计实践>一书中的第1章 ,第1.2.2节,[美] 克里斯托弗·库塞克(Christopher K ...
- 《vSphere性能设计：性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.1.1 确定参数...
本节书摘来华章计算机<vSphere性能设计:性能密集场景下CPU.内存.存储及网络的最佳设计实践>一书中的第1章 ,第1.1节,[美] 克里斯托弗·库塞克(Christopher Kus ...
- 渲染百万网页，终于找到影响性能的原因了
编译 | 明明如月 责编 | 阿哲 出品 | CSDN(ID:CSDNnews) 参考链接:https://itnext.io/we-rendered-a-million-web-pages-to- ...
- 流言粉碎机：JAVA使用 try catch会影响性能
流言粉碎机:JAVA使用 try catch会影响性能 一.JVM 异常处理逻辑 二.关于JVM的编译优化 1. 分层编译 2. 即时编译器 1. 解释模式 2. 编译模式 3. 提前编译器:jaot ...
- 【Unity】Unity中影响性能的几个因素
影响性能的因素 首先,我们得了解,影响游戏性能的因素哪些,才能对症下药.对于一个游戏来说,有两种主要的计算资源:CPU和GPU.它们会互相合作,来让我们的游戏可以在预期的帧率和分辨率下工作.CPU负责 ...
- [V8]找出可能影响性能的代码（模式）
原文地址:Tracing Patterns that Might Hinder Performance 原文作者:Jakub Rożek 译文出自:掘金翻译计划 本文永久链接:github.com/x ...
- 时间轮python_源码笔记：Nodejs 如何高效的获取时间戳而不影响性能的？
本书的好看版本: 本书好看版本:215566435/Fz-node,喜欢的 ,多谢 前言 在昨天方正:玩了将近两年nodejs后,最近发现已经碰到天花板了.希望各位前辈能指点迷津?,的回答中,我提出了 ...
- 别被骗了，try-catch语句真的会影响性能吗？
前言 不知道从何时起,传出了这么一句话:Java中使用try catch 会严重影响性能. 然而,事实真的如此么?我们对try catch 应该畏之如猛虎么? 一.JVM 异常处理逻辑 Java 程序 ...
- try catch真的会影响性能？居然被骗了好几年...
一.JVM 异常处理逻辑 Java 程序中显式抛出异常由athrow指令支持,除了通过 throw 主动抛出异常外,JVM规范中还规定了许多运行时异常会在检测到异常状况时自动抛出(效果等同athrow ...
最新文章
- C++ 与 JAVA区别
- python-yield-生成器--的作用
- phpmyadmin同时连接多个服务器的数据库
- ImportError: cannot import name HTTPSHandler
- jquery vilidate 使用小例
- HA机制的大数据集群的搭建过程
- 数字化转型方法论_50+企业数字化转型、管理的方法论，这本书到底有什么干货？...
- 基于JAVA+SpringBoot+Mybatis+MYSQL的体育馆开放管理系统
- 只有在配置文件或 Page 指令中将 enableSessionState 设置为 true 时，才能使用会话状态。...
- java连接mysql数据库方法_java连接mysql数据库的方法详解
- 基于单片机的智能温度监测系统的代码
- 正则表达式学习实践心得——来源于codesheep（羊哥）
- 在MyEclipse中，如何使用Git将项目上传到G码云仓库
- C#制作UDP协议可同时收发Winform窗体
- PHP赛事贝格尔编排法--单循环
- ElasticSearch 从零到入门
- Tomcat介绍及配置
- 解构SPA模式 ZARA、UNIQLO秘诀
- css样式的叠加,CSS的叠加
- 你知道吗？iPhone7竟然都是机器人组装的
热门文章