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

[Andreas Hocevar]

It will be good to see this "pure JS" approach in action, with actual code. Especially how subclassing and instanceof checking for any class in the inheritance chain would work.

Andreas.

On Oct 22, 2010, at 09:51 , Eric Lemoine wrote:

> 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
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.