Comments for SitePen Blog http://www.sitepen.com/blog SitePen Services and notes about Dojo, DWR, Cometd, JavaScript, and the Web Tue, 13 May 2008 13:13:53 +0000 http://wordpress.org/?v=2.3.3 Comment on Dojo-Mini: Optimization Tricks with the Dojo Toolkit by Dylan http://www.sitepen.com/blog/2008/04/02/dojo-mini-optimization-tricks-with-the-dojo-toolkit/#comment-87245 Dylan Tue, 13 May 2008 13:12:44 +0000 http://www.sitepen.com/blog/2008/04/02/dojo-mini-optimization-tricks-with-the-dojo-toolkit/#comment-87245 @wiwi: We used Apple’s Numbers app, part of iWork 2008. @wiwi: We used Apple’s Numbers app, part of iWork 2008.

]]> Comment on String Performance: an Analysis by Jeroen Ruigrok van der Werven http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87244 Jeroen Ruigrok van der Werven Tue, 13 May 2008 09:35:16 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87244 @Carl: pretty looking, yes, but distorting the facts as well. The 3d appearance of the top of the bars make it hard to determine whether we should read the front or the back of the bar in relation to the lines. Interesting article Tom, but the charts could use less eye-candy and more fact representation. Right now it would be classified as chartjunk. @Carl: pretty looking, yes, but distorting the facts as well. The 3d appearance of the top of the bars make it hard to determine whether we should read the front or the back of the bar in relation to the lines.

Interesting article Tom, but the charts could use less eye-candy and more fact representation. Right now it would be classified as chartjunk.

]]> Comment on Dojo-Mini: Optimization Tricks with the Dojo Toolkit by wiwi http://www.sitepen.com/blog/2008/04/02/dojo-mini-optimization-tricks-with-the-dojo-toolkit/#comment-87243 wiwi Tue, 13 May 2008 06:48:02 +0000 http://www.sitepen.com/blog/2008/04/02/dojo-mini-optimization-tricks-with-the-dojo-toolkit/#comment-87243 Really like the fancy diagram, can I know how you draw that? thanks! Really like the fancy diagram, can I know how you draw that? thanks!

]]> Comment on The Key to Quick Mobile App Navigation by Jason Cline http://www.sitepen.com/blog/2008/05/12/the-key-to-quick-mobile-app-navigation/#comment-87242 Jason Cline Tue, 13 May 2008 05:18:16 +0000 http://www.sitepen.com/blog/2008/05/12/the-key-to-quick-mobile-app-navigation/#comment-87242 Yes, WAP/WML does support the accesskey attribute on links. Phone call support is also supported: http://developer.openwave.com/dvl/support/faqs/faq_wml_programming.htm#11 Jason Yes, WAP/WML does support the accesskey attribute on links.
Phone call support is also supported:
http://developer.openwave.com/dvl/support/faqs/faq_wml_programming.htm#11

Jason

]]> Comment on String Performance: an Analysis by kzyp http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87239 kzyp Mon, 12 May 2008 16:33:45 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87239 Performance with arguments deserves a better explanation: FF performs optimizations where it will not actually build an "arguments" array object unless there is actually a need for to use the "arguments" object with dynamic indexes. When you use arguments[1], FF can optimize that to directly pull the value from the call parameters, rather than creating an arguments object and doing a GetValue on it. Once FF creates the arguments object, it is just as fast as a normal array. When you use dynamic indexes with the arguments object, it is not that FF has a particular performance problem with that, it is simply that turns off an optimization (not creating an unnecessary arguments object), and so you see a performance hit in comparison to the optimized code that doesn't use the arguments with dynamic index access. Performance with arguments deserves a better explanation:
FF performs optimizations where it will not actually build an “arguments” array object unless there is actually a need for to use the “arguments” object with dynamic indexes. When you use arguments[1], FF can optimize that to directly pull the value from the call parameters, rather than creating an arguments object and doing a GetValue on it. Once FF creates the arguments object, it is just as fast as a normal array. When you use dynamic indexes with the arguments object, it is not that FF has a particular performance problem with that, it is simply that turns off an optimization (not creating an unnecessary arguments object), and so you see a performance hit in comparison to the optimized code that doesn’t use the arguments with dynamic index access.

]]> Comment on String Performance: an Analysis by ttrenka http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87238 ttrenka Mon, 12 May 2008 14:18:25 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87238 @Garrett: yes, this was the point of using the BuilderPerf tests first; the JSON serialization battery of tests were intended to take a very common JS task and test different approaches, while looking for hints as to what approaches might be beneficial in other tasks. The recursive nature of that test was the point--especially since the BuilderPerf tests are deliberately *not* recursive in nature. @Ben: wrt to arguments object access, yes that's exactly what we found. The loop unroll I pulled for the FF branch in Builder is what brought the performance of it back down to being comparable or faster than some of the other native operations. As far as the colors and ranges in the graphs are concerned...I *might* be able to fix colors but the ranges are a different story. I used Apple's Numbers (iWork '08) to create the graphs and while they are very pretty, there's not a lot of control you have over how the graphs get rendered :( @Garrett: yes, this was the point of using the BuilderPerf tests first; the JSON serialization battery of tests were intended to take a very common JS task and test different approaches, while looking for hints as to what approaches might be beneficial in other tasks. The recursive nature of that test was the point–especially since the BuilderPerf tests are deliberately *not* recursive in nature.

@Ben: wrt to arguments object access, yes that’s exactly what we found. The loop unroll I pulled for the FF branch in Builder is what brought the performance of it back down to being comparable or faster than some of the other native operations.

As far as the colors and ranges in the graphs are concerned…I *might* be able to fix colors but the ranges are a different story. I used Apple’s Numbers (iWork ‘08) to create the graphs and while they are very pretty, there’s not a lot of control you have over how the graphs get rendered :(

]]> Comment on String Performance: an Analysis by Ben http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87237 Ben Mon, 12 May 2008 13:45:48 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87237 Great work Tom! It's always good to see numbers. I recall trying to use Duff's back when I wrote those tests, but I don't recall it helping. For Bloglines, we try to only use the "once" operations, and we have a little function internally that handles the browser differences. Based on this article I think I'll revisit it and see if I can shave any more time off. In the bit about "dynamic access to the arguments object" being really slow in Firefox, do you mean that going after an item using a variable is slow (vs. a constant)? Like var i = 1, a = arguments[i]; is slower than var a = arguments[1]; ? If so, that's an amazingly weird find. :) A couple really minor nits: the color used to represent each browser changes throughout the article. Any chance you could make it consistent? Also, the scales for some comparative graphs are different; it would help if they were consistent. Great work Tom! It’s always good to see numbers. I recall trying to use Duff’s back when I wrote those tests, but I don’t recall it helping.

For Bloglines, we try to only use the “once” operations, and we have a little function internally that handles the browser differences. Based on this article I think I’ll revisit it and see if I can shave any more time off.

In the bit about “dynamic access to the arguments object” being really slow in Firefox, do you mean that going after an item using a variable is slow (vs. a constant)? Like var i = 1, a = arguments[i]; is slower than var a = arguments[1]; ? If so, that’s an amazingly weird find. :)

A couple really minor nits: the color used to represent each browser changes throughout the article. Any chance you could make it consistent? Also, the scales for some comparative graphs are different; it would help if they were consistent.

]]> Comment on The Key to Quick Mobile App Navigation by Hafeez Bana http://www.sitepen.com/blog/2008/05/12/the-key-to-quick-mobile-app-navigation/#comment-87236 Hafeez Bana Mon, 12 May 2008 07:19:32 +0000 http://www.sitepen.com/blog/2008/05/12/the-key-to-quick-mobile-app-navigation/#comment-87236 Hi Jason, Does this work on WAP sites? hb Hi Jason,

Does this work on WAP sites?

hb

]]> Comment on String Performance: an Analysis by Garrett http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87234 Garrett Mon, 12 May 2008 05:13:34 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87234 The test code is slow because of the recursive approach used to serialize the object (testcode: recursor = arguments.callee). It adds noise to the test. It seems that the results are closer together than if the test performed only concatenation. Have you tried isolating the serialization aspect in one function that does only the concatenation -- no recursion, no serialization, just concatenation? The test code is slow because of the recursive approach used to serialize the object (testcode: recursor = arguments.callee). It adds noise to the test. It seems that the results are closer together than if the test performed only concatenation.

Have you tried isolating the serialization aspect in one function that does only the concatenation — no recursion, no serialization, just concatenation?

]]> Comment on String Performance: an Analysis by Dylan http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87231 Dylan Sat, 10 May 2008 15:59:43 +0000 http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/#comment-87231 The graphs were generated with Numbers, part of Apple's iWork suite. The graphs were generated with Numbers, part of Apple’s iWork suite.

]]>