编写自己的解析器值得花费额外的运行时间吗？
我正在做涉及大量 DOM 操作的工作。我编写了一个函数，可以使用“热键”更有效地更改对象的常见样式。它简单地解释了这一点：
styles = parseStyles({p:"absolute",l:"100px",t:"20px",bg:"#CC0000"});
如下：
styles = {position:"absolute",left:"100px",top:"20px",background:"#CC0000"};
这主要是为了让我免于阅读太多内容，并且因为我想看看我是否可以做到:)（以及文件大小）。我发现这些热键更容易查看；我为不同的自定义 DOM 对象设置和重置样式数十次。
但是，如果我的页面在一个会话中使用它多达 5,000 次（一次大约执行 10-25 次），这样的瓶颈是否会对性能和运行时造成重大负担？
function parseStyles(toParse){
var stylesKey =
{h:"height",p:"position",l:"left",t:"top",r:"right",b:"bottom",bg:"background"},
parsedStyles = {};
for (entry in toParse){
if (entry in stylesKey){
parsedStyles[stylesKey[entry]] = toParse[entry];
} else {
parsedStyles[entry] = toParse[entry];
}
}
return parsedStyles;
}
I am doing work involving a lot of DOM manipulation. I wrote a function to more efficiently change common styles on objects using "hotkeys". It simply interprets this:
styles = parseStyles({p:"absolute",l:"100px",t:"20px",bg:"#CC0000"});
as this:
styles = {position:"absolute",left:"100px",top:"20px",background:"#CC0000"};
This came about mainly to save me from having to read so much, and because I wanted to see if I could do it :) (as well as file sizes). I find these hotkeys easier to look at; I am setting and resetting styles dozens of times for different custom DOM objects.
But, is having a bottleneck like this going to be a significant burden on performance and runtime if my page is using it up to 5,000 times in a session, about 10-25 executions at a time?
function parseStyles(toParse){
var stylesKey =
{h:"height",p:"position",l:"left",t:"top",r:"right",b:"bottom",bg:"background"},
parsedStyles = {};
for (entry in toParse){
if (entry in stylesKey){
parsedStyles[stylesKey[entry]] = toParse[entry];
} else {
parsedStyles[entry] = toParse[entry];
}
}
return parsedStyles;
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现很少再需要设置非计算样式了。如果您提前知道样式，请在 CSS 中为其定义一个类，并从必要的对象中添加或删除类。您的代码更易于维护，并且所有特定于样式的信息都位于您的 CSS 文件中，而不是 Javascript 文件中。几乎，我唯一一次直接在对象上设置格式样式信息是当我使用绝对定位的计算位置时，即使如此，如果我绞尽脑汁，定位问题通常可以用纯 CSS 解决/HTML。
您在问题中引用的示例看起来像静态样式，这一切都可以通过 CSS 规则来完成，并且只需对对象执行 addClass 即可。除了更干净之外，执行速度也应该快得多。
看起来您正在做的事情是使用运行时解析来节省开发时的输入。如果您没有注意到性能差异，那也没关系。只有您可以确定这一点，因为只有您可以在需要运行的环境（旧浏览器、旧 CPU、压力使用）中测试您的应用程序。我们无法为您解答。对于开发时已知的内容不进行运行时转换肯定会更快。这种速度差异是否相关取决于您尚未披露（甚至可能没有认真考虑过）的大量细节和应用程序要求，并且只能通过配置测试来确定。
如果是我，并且我有任何想法，也许我调用得太多以至于可能会影响性能，我会发现做一些额外的输入（或搜索和替换）并且不必测试潜在的性能问题。
I find that setting non-computed styles is rarely ever needed any more. If you know the styles ahead of time, define a class for that in your CSS and addClass or removeClass from the necessary objects. Your code is a lot more maintainable and all style-specific info is in your CSS files rather than your Javascript files. Pretty much, the only time I set formatting-style info directly on an object anymore is when I'm using computed positions with absolute positioning and even then, if I rack my brain hard enough, the positioning problem can usually be solved with plain CSS/HTML.
The examples you cite in your question look like static styles which could all be done with a CSS rule and simply doing addClass to an object. Besides being cleaner, it should be a lot faster to execute too.
It looks like what you're doing is using run-time parsing in order to save development-time typing. That's fine if you don't notice the performance difference. Only you can know that for sure because only you can test your app in the environments that you need it to run (old browser, old CPU, stress usage). We can't answer that for you. It would certainly be faster not to be doing run-time conversion for something that is known at development time. Whether that speed difference is relevant depends upon a lot of details and app requirements you haven't disclosed (and may not have even seriously thought about) and could only be figured out with configuration testing.
If it were me and I had any thoughts that maybe I was calling this so much that it might impact performance, I'd find it a lot less work to do a little extra typing (or search and replace) and not have to test the potential performance issues.
记住你的解析函数。
简单的事实是，在某些有限的时间内，您将处理的实际样式或完整样式字符串的数量可能会非常小，并且也可能有合理数量的重复。
因此，当您解析样式表达式时，您可以执行一些简单的操作，例如将表达式存储在映射中，并检查您以前是否见过它。如果有，请返回之前得到的结果。
当涉及重用时，这将为您节省大量时间，而当不涉及重用时，这可能不会花费您太多时间。
Memoize your parsing function.
The simple fact is, that over some finite area of time, the number of actual styles, or full style strings that you will process will likely be quite small, and will also, likely, have a reasonable amount of duplication.
So, when you go to parse a style expression, you can do something simple like store the expression in a map, and check if you've seen it before. If you have, return the result that you got before.
This will save you quite a bit of time when reuse is involved, and likely not cost you much time when it's not.