编写自己的解析器值得它带来额外的运行时吗？

Question

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;
}

Answer 1

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.

Answer 2

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.