假设我们有下一个函数：
const x = a => a;
const result = x('hello')
我们在 Google V8 / Firefox Quantum 中是否有任何保证：x将被优化为const result = 'hello'?
我为什么要问它？
请看我的answer https://stackoverflow.com/questions/66851513/a-way-to-mark-arbitrary-strings-in-typescript-template-literals#answer-66852494。有时，在 TypeScript 中推断类型的唯一方法是创建简单的函数。
type Validation<T> = T
const x = <T>(arg:Validation<T>)=>arg
这是一个开销。所以，我很好奇，我可以使用这种技术进行类型推断并且不用担心函数开销吗？
（V8 开发人员在此。）
一般来说：没有保证关于哪些内容会或不会得到优化。引擎的优化决策也会随着时间的推移而变化：目标不是尽可能优化（因为优化本身的成本并不总是值得的）；目标是在正确的时间优化正确的事情。这很可能意味着工程团队决定稍微减少引擎优化，以获得更好的整体性能（或更少的卡顿，或更少的内存消耗，或其他）。
在这种特定情况下可能会发生什么：这取决于（像往常一样）。如果该函数的定义及其调用站点是顶级代码（执行一次），则它很可能不会得到优化 - 因为优化此类代码通常不值得。您将无法测量差异，但如果您能够测量它，您会发现对于仅运行一次的代码，不优化速度更快。
另一方面，如果从“热”代码调用此恒等函数，一段时间后选择该热代码本身进行优化，那么优化编译器很可能会内联该函数，然后（简单地）优化把它带走。
If the 定义重复执行恒等函数，那么（至少在发生内联之前/除非发生内联）这将不必要地创建多个函数对象（因为 JavaScript 函数具有对象恒等）。这是一种很容易避免的低效率（所以我个人会避免它）；但再次强调：它是否真的重要，即是否具有可测量的效果，取决于代码执行的频率。
简而言之：在这种情况下，不必担心函数开销可能很好；然而，不能保证对恒等函数的调用会得到优化。
（退后一步，看看更广泛的背景：我对 TypeScript 的高级功能了解不多，但我的直觉是，TS 编译器的某种插件可能是对文字强制执行特定类型检查的更优雅的方式。如果字符串是在运行时构造的，那么 TS 的检查无论如何都不会有帮助，就像 TS 类型检查系统的其余部分一样。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
