- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 27 Jul 2009 12:25:55 -0400
- To: Jeff Schiller <codedread@gmail.com>
- CC: www-svg <www-svg@w3.org>
Jeff Schiller wrote: > Are there performance benefits to having two methods (one to write and > one to read markup) rather than having a read-write attribute or are > they compiled by the browser down to the same thing? It really depends on implementation details. To be specific, let's compare |x.foo = "y"| to |x.setFoo("y")|. In theory, the former looks something like this: 1) Look up the "foo" property on the prototype chain of "x". 2) Call the setter you find with "x" as |this|. Also in theory the latter looks something like this: 1) Look up the "setFoo" property on the prototype chain of "x". 2) Call the getter you find with "x" as |this|. 3) Call the resulting function object with "x" as |this|. So in theory the former is faster. Now in practice (and most of what follows is Gecko- and SpiderMonkey-specific), step 1 in both the above algorithms can be and is optimized in various ways in ECMAScript implementations, and the optimizations may not be the same for function-valued properties and other properties (I believe they are not in SpiderMonkey, in fact). Furthermore, as shipped in Gecko 1.9.1 SpiderMonkey's tracing jit can trace across certain DOM method calls but not across DOM getters and setters. This will likely change; hopefully in Gecko 1.9.2. So for right now the method approach would be faster in Gecko, but in a few months that might no longer be the case. Except for situations like the jit one, I think the performance difference between the to is likely to be very small; it's not worth worrying about it in terms of deciding which API to prefer. Especially because you don't know which one will actually be faster in the cases when the optimizations for the lookup step are different for the two cases. -Boris
Received on Monday, 27 July 2009 16:26:52 UTC