ConfigProvider 性能开销大 about ant-design HOT 9 CLOSED

@zombieJ 大致定位到三个最主要的性能消耗来源：

1. @ant-design/cssinjs 的 useCacheToken() 和 useCSSVarRegister() (19ms)
2. @ant-design/colors 的 inputToRgb() 和 toHex() (20ms)
3. rc-motion 的 CSSMotion 和 CSSMotionList (13ms)

from ant-design.

<ConfigProvider> 没有加 theme 属性的话，是不是不需要有 cssinjs 相关的处理？

挖了一下。CP 中有一个 useStyle(iconPrefixCls, csp) 用来处理设置 iconPrefixCls 来改变的场景（因为 @ant-design/icons 并不被 antd 管理）。以至于 theme 的 token 计算被提前到了 CP（相当于原本 Button 渲染启动的 token 计算被提前了）。这个 token 计算时间无论是在 CP 中还是在 Button 中都是一次性的。所以在不变化主题时，这个损耗可以被无视掉。

（算过一次后，之后渲染只有 Button 元素自身的损耗）

from ant-design.

Start a new pull request in StackBlitz Codeflow.

• react-n4zzdv-uvvtrc (Open reproduction)

from ant-design.

聚合数据应该没这么慢才对，估计是什么地方有计算损耗。直接帮忙看看？~

from ant-design.

同样是使用 css-in-js 的 Material UI 的 ThemeProvider 要比 Ant Design 的 ConfigProvider 要快 60ms 左右：

Material UI

Ant Design

from ant-design.

@guoyunhe 帮忙排查一下具体问题所在吧，能来 PR 最好啦~

from ant-design.

1. 初始化默认主题时，会将默认主题/自定义主题所有 color 实例化，这一过程过于耗时，但是实际上并不是所有的地方都需要实例化的 color 去进行颜色的计算。最好的情况肯定是避免实例化主题的颜色 token，在实际需要的时候再进行实例化，很多地方可以用 CSS 的 color-mix 来替代 JS color 计算。但这种改动不可避免地会产生破坏性变更，大佬们在 v6 考虑一下吧。
2. css-in-js 我觉得还是性能瓶颈，优化算法可以缓解，但是不可能根除，v6 版本是否重回 less 或 sass？
3. rc-motion 用了一些 rc-util 的函数 findDomNode, useState, 貌似效率不高，而且自身也逻辑太多。

from ant-design.

cssinjs 中获取完整的 design token 对业务里复用会比较方便，否则要做复杂计算（比如当 padding < 10 时使用样式 A，反之使用样式 B），开发者是无法从 css var 中感知的。此外，计算取整都是 cals 的弱项。

但是提到的完整主题计算的确是一个点，感觉可以想办法优化一下。

rc-motion 当子元素支持 dom ref 时不会调用 findDOMNode。逻辑多是需要的，rc-motion 对动画阶段进行了拆分从而可以让上游做更精细的管理。

from ant-design.

<ConfigProvider> 没有加 theme 属性的话，是不是不需要有 cssinjs 相关的处理？

from ant-design.