Home Tutorials Forums Articles Blogs Movies Library Employment Press
Old 08-06-2012, 02:47 PM   #1
santanoa
Dual Screen Empowered
 
santanoa's Avatar
 
Join Date: Jul 2010
Location: Israel
Posts: 258
Default Too many constants?

My question that I pose to you is:

Is it possible to have too many constants in a project. Right now, I've reached around 50. I love 'em.

The reason I ask is because I heard that setting variables before the constructor is slower than setting them after. I don't see why, but that's why I'm asking


Thanks!
santanoa is offline   Reply With Quote
Old 08-06-2012, 04:45 PM   #2
-:)lauri
Senior Member
 
Join Date: Aug 2008
Location: Helsinki, Finland
Posts: 1,184
Default

I tested that with 3000 items. I got this kind of results:

consts
ActionScript Code:
import flash.utils.getTimer; const VAL0:Number = 0; //... const VAL2999:Number = 54.76312628037227; function init():void {     trace(getTimer()) // ~ 13.1 ms } init();

defined vars
ActionScript Code:
import flash.utils.getTimer; var val0:Number = 0; //... var val2999:Number = 54.76312628037227; function init():void {     trace(getTimer()) // ~ 17.9 ms } init();

vars defined dynamically (1)
ActionScript Code:
import flash.utils.getTimer; var val0:Number; //... var val2999:Number; function init():void {     setVars(); } function setVars():void {     for(var i:uint = i; i < 3000; i++)     {         this["val"+i] = Math.sqrt(i);     }     trace(getTimer()); // ~ 18.2 ms } init();

vars defined dynamically (2)
ActionScript Code:
import flash.utils.getTimer; var val0:Number; //... var val2999:Number; function init():void {     for(var i:uint = i; i < 3000; i++)     {         this["val"+i] = Math.sqrt(i);     }     trace(getTimer()); // ~ 18.8 ms } init();

...constants seems to be in this situation fastest to define. At least in compiling in Flash.

Last edited by -:)lauri; 08-06-2012 at 04:55 PM.
-:)lauri is offline   Reply With Quote
Old 08-06-2012, 04:52 PM   #3
santanoa
Dual Screen Empowered
 
santanoa's Avatar
 
Join Date: Jul 2010
Location: Israel
Posts: 258
Default

Cool dude. Thanks for the info!

p.s. how do you pronounce your name? is it smiley-laurie or dash-colon-end-parentheses-laurie?
santanoa is offline   Reply With Quote
Old 08-06-2012, 05:04 PM   #4
-:)lauri
Senior Member
 
Join Date: Aug 2008
Location: Helsinki, Finland
Posts: 1,184
Default

"dash-colon-end-parenthesis"-lauri for Robert Langdons and "smiley"-lauri for rest of us
-:)lauri is offline   Reply With Quote
Old 08-15-2012, 07:11 AM   #5
Mazoonist
Site Contributor
 
Mazoonist's Avatar
 
Join Date: Jun 2006
Posts: 3,160
Send a message via AIM to Mazoonist
Default

Nice work, lauri!

Anyway, I Googled "how fast is the blink of an eye" and I found this:
"On average, a human eye takes between 300 and 400 milliseconds to complete a single blink. That's roughly between three-tenths and four-tenths of a second."

Read more: How Fast Is a Blink of an Eye? | eHow.com http://www.ehow.com/about_5199669_fa...#ixzz23azqmoSZ

Now, if it takes between 300 and 400 ms. to blink your eye (on average), how fast do you think 13 to 18 ms. is? Your computer defining 3000 constants or variables that fast is definitely amazing. Now imagine how many you'd have to define to cause a noticeable slowdown. Yeah, your 50 constants is indeed nothing.

I am writing this because I think that many times we worry unnecessarily about performance issues when we haven't really bumped up against any limitation or noticed any slowdown. There are things that will slow down your computer and cause performance issues, but I think we need to experience them and figure out what they are, and then go about fixing them, otherwise we might wind up worrying about things that turn out to be non-issues.
__________________
My Tutorials * My Website
Mazoonist is offline   Reply With Quote
Old 10-05-2012, 02:11 PM   #6
glantucan
newbe forever!
 
glantucan's Avatar
 
Join Date: Oct 2004
Location: Madrid, Spain
Posts: 88
Default

Not only that, the point of optimizing your code for performance, is to do it when it really matters. 300 ms can be a pain in the ass if spent every frame on some unnecesary calculation, but are nothing on your application initilization, when your constants are actually evaluated.
__________________
glantucan
glantucan is offline   Reply With Quote
Old 10-06-2012, 02:45 PM   #7
wvxvw
Holosuit User
 
wvxvw's Avatar
 
Join Date: Oct 2006
Location: Tel Aviv
Posts: 4,301
Send a message via ICQ to wvxvw
Default

OK, I'll try to give a more "scientific" answer to this question.
Im most compiled languages constant means something entirely different from what it is in AS3. Normally, it helps compiler realize that the value being referenced isn't going to change, so it is free to do with it whatever it likes (assuming the value doesn't change). This allows for optimizing the memory space used and helps identifying redundant null-checks on the code etc.
In the context of AS3 constants are... well, they are class fields. There are two kinds of constants. They can be of primitive type (numerical, string or a logical value), or complex type (everything else).
When you deal with constants which are language primitives - this is no different at all then you accessing fields of a sealed class. No speed improvement on top of that. Contextually, the keyword const may be used inside a function to specify that a local function variable is not going to change during that function execution - this, exept for compiler validation has no effect on speed, and if you replace it by var keyword - absolutely nothing will change.
Complex types of constants are absolutely not affected by the fact they are constants. They behave just like any other complex object, you can dynamically change the value of fields, and if an object itself is dynamic, you can also add or delete its fields.

Now, to the question of speed: will, in theory, a large number of constants reduce performance of field access time?
To answer this question we need to understand, that our objects are string or integer hashes. When the object was created from dynamic class, it will have two hash tables - one for sealed properties, and another one for dynamically added properties. When you access the first kind (and your constants will certainly be the first type), it is a guaranteed O(1) time. Now, you may wonder what's operation actual cost - well, this probably depends on many factors, given your platform (64 bit or 32 bit), and the particular hash table implementation being used for the Flash objects.
The most common hash table implementation is a binary tree - this guarantees finding values given their key in constant time, while the effort required to do that grows in logarithmic time (very slow).
So, in practice, you may notice a difference between the time it would take to access the property of an object having number of properties multiples of power 2, but most likely the default allocation doesn't start at small values. Let's assume the first time the hash table is created it allocates enough memory to store 128 properties (this may be a sensible default). Then you'd see then the hash table was rehashed after it passes this threshold; the next time this would happen would be when you have 256 properties (few classes in Flex framework have that much, but sane programmers don't usually create such big classes). The next hop is at 612, the next after it is at 1024 - it's highly unlikely that you will ever use a class with this many properties.

Conclusion: in your everyday practice the number of constants you've defined in a class will not affect the performance of your code, but even if you created so many of them that it actually has some influence on that, that influence will be vanishingly small.
__________________
The .NET open source editor for Flash and web developers
*This would be my contribution to the project*
couchsurfing if you need it
wvxvw is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 03:29 AM.

///
Follow actionscriptorg on Twitter

 


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2013 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.