08-06-2012, 02:47 PM
|
#1
|
|
Dual Screen Empowered
Join Date: Jul 2010
Location: Israel
Posts: 253
|
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!
|
|
|
08-06-2012, 04:45 PM
|
#2
|
|
Senior Member
Join Date: Aug 2008
Location: Helsinki, Finland
Posts: 1,133
|
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.
|
|
|
08-06-2012, 04:52 PM
|
#3
|
|
Dual Screen Empowered
Join Date: Jul 2010
Location: Israel
Posts: 253
|
Cool dude. Thanks for the info!
p.s. how do you pronounce your name? is it smiley-laurie or dash-colon-end-parentheses-laurie?
|
|
|
08-06-2012, 05:04 PM
|
#4
|
|
Senior Member
Join Date: Aug 2008
Location: Helsinki, Finland
Posts: 1,133
|
"dash-colon-end-parenthesis"-lauri for Robert Langdons and "smiley"-lauri for rest of us
|
|
|
08-15-2012, 07:11 AM
|
#5
|
|
Site Contributor
Join Date: Jun 2006
Posts: 3,160
|
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.
|
|
|
10-05-2012, 02:11 PM
|
#6
|
|
newbe forever!
Join Date: Oct 2004
Location: Madrid, Spain
Posts: 88
|
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
|
|
|
10-06-2012, 02:45 PM
|
#7
|
|
Holosuit User
Join Date: Oct 2006
Location: Tel Aviv
Posts: 4,299
|
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.
|
|
|
| Thread Tools |
|
|
| Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT. The time now is 06:43 AM.
///
|
|