执行此操作的最快方法?三元运算符?转变?大批?
执行此操作最快的方法是什么?左侧括号中的变量返回布尔值,它们代表窗口大小范围。 (例如,o1281
对于屏幕 1281 及以上返回 true
,o1025
对于 1025 及以上返回 true
,等等。)
markup = // ternary triangle (the rows set the markup priority at each band)
( o1281 ) ? r1281 || r1025 || r961 || r641 || r481 || r320 || r0 || omarkup:
( o1025 ) ? r1025 || r961 || r641 || r481 || r320 || r0 || omarkup:
( o961 ) ? r961 || r641 || r481 || r320 || r0 || omarkup:
( o641 ) ? r641 || r481 || r320 || r0 || omarkup:
( o481 ) ? r481 || r320 || r0 || omarkup:
( o320 ) ? r320 || r0 || omarkup:
( o0 ) ? r0 || omarkup:
omarkup;
我想也许可以根据中间(o641
)条件将其分成 2 个范围。
值得吗?
What is the fastest way to perform this? The vars in the parens on the left return boolean and they represent window size ranges. (e.g. o1281
returns true
for screens 1281 and up, o1025
returns true
for 1025 and up, etc.)
markup = // ternary triangle (the rows set the markup priority at each band)
( o1281 ) ? r1281 || r1025 || r961 || r641 || r481 || r320 || r0 || omarkup:
( o1025 ) ? r1025 || r961 || r641 || r481 || r320 || r0 || omarkup:
( o961 ) ? r961 || r641 || r481 || r320 || r0 || omarkup:
( o641 ) ? r641 || r481 || r320 || r0 || omarkup:
( o481 ) ? r481 || r320 || r0 || omarkup:
( o320 ) ? r320 || r0 || omarkup:
( o0 ) ? r0 || omarkup:
omarkup;
I was thinking maybe break it into 2 ranges based on the middle (o641
) condition.
Is it worth it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,你要做的就是按降序查找第一个真实的 o 值,一旦找到,你就会寻找第一个真实的 r 值,其名称为
<=
这个 o -价值。如果没有找到,您希望返回值omarkup
。因为您只有几个 o 值和 r 值,所以您的代码尽管可能很“有趣”,但似乎可以进行最少的测试。
我看不出开关或哈希有什么帮助,因为您似乎确实在按降序搜索第一个真值......因此,我不明白为什么分割也会有助于性能。保持原样,或者,如果您更喜欢可读性(正如许多程序员所做的那样),请创建将 1281、1025 等作为字段的对象。
此外,当面临要执行很多次的操作时,人们通常会担心性能。这里是这样吗?假设 o 和 r 值不变,这看起来像是只执行一次的事情。 (仅供参考。)
ADDENDUM
根据添加到上述问题的注释,它看起来像是您想要执行多次的操作。在这种情况下,尽管现代编译器非常好,但在 JavaScript 级别进行自我优化可能是可以的。从代码审查的角度来看,最大的担忧是值 1281、1025、961、941 等是手动布置的并且是源代码的一部分,因此维护(例如在此处添加新的大小值)是,好吧,棘手且容易出错。也就是说,根据您所展示的内容,我认为可以肯定地说,您编写的 JavaScript 是对于一个简单的编译器来说是最好的。您始终可以寻求一个只定义一次这些值的实现,然后对其进行分析以查看它是否“足够快”。例如,您可以定义一个数组,例如
和 循环,但是,这样的实现会产生开销。
在这里可能对您有帮助的一个问题是仔细考虑什么可以缓存,什么不可以缓存。这有助于加快此代码的未来执行速度。
Okay so what you are doing is looking for the first truthy o-value going in descending order, and once you find one you are looking for the first truthy r-value whose name is
<=
this o-value. Finding none, you wish to return the valueomarkup
.Because you only have a few o-values and r-values, your code, as "interesting" as it may be, appears to make the least number of tests possible.
I can't see how switches or hashes would help, since you do appear to be searching in descending order for the first truthy value.... Because of this, I don't see why splitting would help performance either. Leave it as is, or, if you prefer readability (as many programmers do), make objects for which 1281, 1025, etc. are fields.
Also, worrying about performance is usually something one does when faced with an operation that will executed many, many times. Is this the case here? This looks like something you would only execute once, assuming the o and r values don't change. (Just an FYI.)
ADDENDUM
Based on the comment added to the question above, it looks like an operation you would like to execute multiple times. In this case it probably okay to self-optimize at the JavaScript level, although modern compilers are pretty good. The biggest concern from a code-review perspective would be that the values 1281, 1025, 961, 941, and so on are laid out manually and are part of the source code, so maintenance, such as adding new size-values here is, well, tricky and error-prone. That said, based on what you have shown, I think it is safe to say your JavaScript as written is the best obtainable given a naive compiler. You can always shoot for an implementation that defines these values exactly once and then profile it to see if it is "fast enough". For example you can define an array such as
and loop through, but yes, there is overhead in such implementations.
One issue that might help you here is to consider carefully what can and cannot be cached. This could help speed up future executions of this code.