[OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix.

[Tim Schaub]

Yeah, this is a standard JS optimization technique.

Note that it is strictly slower to concatenate a handful of strings with 
array.join, but it is good practice for largish numbers.

And, no new methods needed in my mind.

Another thing to keep in mind is that any time you know the number of 
elements in the array, it is better to initialize the array with a 
length (instead of using push).

That is:

// worst
var str = "";
for(var i=0; i<elements.length; ++i) {
   str += "junk";
}

// better
var pieces = [];
for(var i=0; i<elements.length; ++i) {
   pieces.push("junk");
}
var str = pieces.join("");

// best
var numElements = elements.length;
var pieces = new Array(numElements);
for(var i=0; i<numElements; ++i) {
   pieces[i] = "junk";
}
var str = pieces.join("");


Note that this is a big part of how I got a ~5x improvement in the GML 
parsing.  Anyway, googling for efficient javascript is a good idea for all.

Tim

Erik Uzureau wrote:
> On 10/16/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
>> On Wed, Oct 17, 2007 at 11:58:17AM +1000, Roald de Wit wrote:
>>> The same slowdown most probably applies to the other drawing methods in
>>> this class.
>>>
>>> My question is: what would be the best way to tackle this?
>> Interesting. I'd always followed the type of behavior you're suggsting
>> in Python, but had never known it was needed in JS. (It's always bugged
>> me that we just shoved strings together in Javascript, but it seemed
>> like everyone did it, so I didn't question.)
>>
>> The typical way I do this in Python is to just do the equivilant of:
>>
>> var stringList = [];
>> for (var i = 0; i < 10000; i++) { stringList.push('foo'); }
>> var string = stringList.join("");
>>
>> I think we can even skip the .join("") and use .toString() in JS, but I
>> have no idea how portable that is, and it feels slightly hacky.
>>
>> So, I don't see any need for a stringBuffer object, since it would just
>> be an array (with 'push' replaced with 'append').
>>
>> With these performance numbers in hand, I think that migrating any
>> significant use of string concatanation -- which I think only includes
>> the renderers, and maybe things like getParameterString -- to be array
>> based makes sense, and I'm in support of that path. It probably makes
>> sense to write at least basic tests for the renderer functionality
>> before proceeding with this, to ensure that it doesn't break with the
>> new code in any way that we can be aware of ahead of time.
> 
> Wow. Cool trick. Can't see where else in the OL code it would make
> much of a difference other than:
> 
> -GeoRSS parseData() -- 197
> - BaseTypes String camelize -- 87
> 
> how many times is getParameterString() called?
> 
> e
> 
> 
> 
> 
> 
>> Regards,
>> --
>> Christopher Schmidt
>> MetaCarta
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47158827285493668746562!
>