Comments on: Constructor Slowdown?

By: jackson

jackson — Wed, 24 Nov 2010 01:50:47 +0000

I always test with a release build in a release version of the Flash Player browser plugin. Debug performance is almost always vastly slower and, frankly, irrelevant since end users are almost never running the debug version.

By: Justin Mclean

Justin Mclean — Wed, 24 Nov 2010 01:37:15 +0000

Did you run the tests as a release compile in the release version (ie non debug) of the Flash Player? If you do I think you will find there is a difference – that’s been my experience anyway.

By: jackson

jackson — Wed, 24 Nov 2010 01:28:48 +0000

There’s definitely a chance that it’s just hard to come up with an example where constructors are slower than other functions, but it’d be really good to know if there are cases where constructors actually are slower. Let me know what you find out once you’ve got a chance to dig in.

By: manu

manu — Wed, 24 Nov 2010 01:21:32 +0000

I agree with you and am still am looking for a “constructor” slowdown example… WIth AS3 everything is jitted except for $cinit and $init functions which are not constructors that are called everytime you create a new object. So I have not seen any slowdowns like what this other person claims in the link below in real example :(

I am waiting for my copy of Visual Studio 8 to arrive pretty soon so that I can compile tamarin and dig into the object creation sequence in the VM….

http://blog.classsoftware.com/index.cfm/2010/11/4/Heavy-constructor-JIT-optimisation-in-ActionScript#c33099700-D56E-59C1-07EACFF9ED89BF3A

By: bwhiting

bwhiting — Wed, 20 Oct 2010 11:26:02 +0000

I wrote this a wee while ago but never posted it being lazy
http://blog.bwhiting.co.uk/?p=69

but now I have, maybe of interest to you to see what is going on under the hood.

By: jackson

jackson — Wed, 15 Sep 2010 19:13:29 +0000

I never run my performance tests in the content debugging player. The point of the article is to debunk the myth that– for whatever reason– code in a constructor executes slower than code outside of a constructor.

By: Henke37

Henke37 — Wed, 15 Sep 2010 19:11:24 +0000

I think the issue is simple: constructors are interpreted instead of JITed. But the content debugging players doesn’t use JITing apparently. So the test is flawed, assuming that it was run in a content debugging player.

By: jackson

jackson — Wed, 16 Sep 2009 19:12:33 +0000

Thanks for the comment. The point of the article was to show that there is no performance gain or loss either way. It simply doesn’t matter if the code is in the constructor or an init() function. I did try a few other types of constructors, including some making calls to more native-heavy code like Math.sqrt(), and saw no difference, so I posed just this.

I agree about when to use init() over constructors. Object re-use is a big deal when trying to eliminate GC slowdown and allocation time. It also allows free lists, as today’s article points out. Personally, I like to do just as much in the constructor as is necessary for the object to be constructed in a valid, known state, per the RAII approach. Then the user should call init() or other functions to further set up the object as required.

Thanks again for the comment.

By: Alec McEachran

Alec McEachran — Wed, 16 Sep 2009 19:07:17 +0000

Thanks for the interesting article.

I’m not sure you can call that a performance improvement because the margin of error is so slim; you’d need a much bigger sample of constructors to have any confidence.

As a performance-irrelevant aside, I have two reasons to favour init over the constructor:

1. You can call super.init(…) from anywhere in a sub-class’s init method;

2. Once you construct a super-class with parameters the compiler commits you to writing out that constructor for any sub-class.

They’re good enough to prefer init over the constructor when no other overriding reason presents itself, in my opinion.

Regards, Alec.