On Nov 28, 2009, at 10:09 PM, Boris Zbarsky wrote: > This is not an issue at all; any XULRunner application can be run in Firefox > directly (with the right command-line flags). I'm happy to profile whatever > set of operations you want for you in Firefox if you send me step-by-step > instructions for performing that set of operations in your application, > ideally with code pointers to the start and stop of the code to be profiled > in your codebase. Probably offlist for all that... ;) Ah, but this is trouble for me because I am still a novice with XULRunner and related technologies! Thank you for your offer.
> Of course if you have a Mac you can do all this yourself; Shark is an > excellent tool. I've tried using Shark to profile the long-running portion of the code, but symbols captured are mostly alien to me, and I have no idea what I'm really looking at; especially as it relates to JavaScript/Tracemonkey. >> Changeset 2b56c4771d5c reduced the number of pixel array elements >> accessed by caching the 256px x 256px "rooms" within the stage map, and >> passing the cached rooms to putImageData(). > > As opposed to doing what before the change? The previous code used a "non-cached" approach. Where every pixel in the canvas was explicitly drawn into the ImageData array. Keep in mind, the largest of these was 4864px × 3072px. If anything, the change took time away from JavaScript and placed it in native code: putImageData(). >> My point, as you concur, is that setting four array elements >> (properties) is slower than setting just one. > > While true, it may not necessarily be slower than setting one if the value to > set is more expensive to compute as a result, and may not be the bottleneck > to start with. The latter is hard to determine without profiling. My gut > feel is that at least in Gecko this is not likely to be a performance > bottleneck right now, nor much of a win with the proposed change, if any. > But again, that would be easier to judge (at least for the first part) with a > profile. This is an excellent point that I should reconsider. My impression is from the C language, where single array element accesses can be considered to take the same amount of time, regardless of the data size. And this is difficult to determine with JavaScript (even across the different engines) without some hard benchmarking numbers.
