[OpenLayers-Dev] Re: [OpenLayers 3] type instantiation performance

[Eric Lemoine]

On Friday, October 22, 2010, Andreas Hocevar <ahocevar at opengeo.org> wrote:
>
> On Oct 22, 2010, at 07:27 , Eric Lemoine wrote:
>
>> On Thursday, October 21, 2010,  <christopher.schmidt at nokia.com> wrote:
>>>
>>> On Oct 21, 2010, at 4:45 PM, ext Xavier Mamano (jorix) wrote:
>>> Good appreciation Andreas, now Chome is still the best but it's not a
>>>>
>>>> miracle :-)
>>>
>>>
>>> Er, not to be too critical here or anything, but it does look like
>>> Safari beats Chrome in every case except the one we're trying to
>>> discuss throwing away :)
>>
>> Jorix's number also show that "Object Litteral" doesn't lead to
>> significantly better performance than "Pure JavaScript", which makes
>> me think making this change in the lib is really worth it.
>
> The advantage of object literals is that it's straight forward.

I think going from "OpenLayers.Class" to "Pure JS Type" is even more
straight forward—no refactoring would be needed as method calls on
objects will continue to work.

> We do have OpenLayers.Class, which gives us many advantages (like instanceof checking).

Having instanceof work is a must-have. And using "Pure JS Type", as I
proposed, would't break that.

> So instead of introducing a new hybrid with an inherit function (remember: we got rid of one 3 years ago),

This is a different situation. Previously we have OpenLayers.Class for
creating base classes and OpenLayers.Class.inherit for creating
subclasses. We simplified this in such a way that OpenLayers.Class can
be used to define both base classes and subclasses. I'm proposing to
simplify even more, by using pure JS types for defining base classes
and a simple, minimal "extend" function for defining subclasses. So,
to me, this isn't going back, but moving forward.

> I'd say two things are in order:
>
> * Revisit OpenLayers.Class. Obviously there is room for improvement in there.

If we want to avoid the initialize.apply calls, which cost, "Pure JS
Types" for base classes is the way to go.

> * Allow the use of object literals wherever possible.

I think we should first remove OpenLayers.Class, which wilm yield
performance improvements. And once done, we can use object litterals
where it makes sense.


> The latter really isn't that much effort. For example, wherever we want to show the user a string representation of a pixel, we currently would do:
>
> alert(pixel.toString());
>
> If we accept an instance of OpenLayers.Pixel or an object literal, we can safely do
>
> alert(OpenLayers.Pixel.prototype.toString.call(pixel);
>
> No need to distinguish between an OpenLayers.Pixel instance and an object literal.

Yes.

That being said, we create lots of Bounds when panning the map, and
using object litterals for Bounds isn't as straight forward because of
the containsBounds method and friends we apply.

And again, using "Pure JS Types" gives us good performance, even
better performance than object litterals in some browsers.


>
> And speaking of room for other performance improvements: we often create clones internally where we would not need to. This is also very expensive.

Definitely. And it's expensive because we do initialize.apply
currently. I wouldn't be as expensive if using "Pure JS Types".

Cheers,

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine at camptocamp.com
http://www.camptocamp.com