We are in the process of the optimization of a Flex AS3 Application.
One of my team members suggested we make the variable name lengths smaller to optimize the application performance.
I.e.:
var IsRegionSelected:Boolean = false; //Slower
var IsRS:Boolean = false; //faster
Is this true?
No, the gain you will obtain will be only for the size of the swf.
String are put into a constant pool and instruction refering to this String will use an index.
it can be seen as (very schematic) :
constant pool:
[0] IsRegionSelected
[1] IsRS
usage:
value at 0 = false
value at 1 = false
Your code will be probably translated as (for local variable):
push false
setlocal x
push false
setlocal y
where x and y are register int assign by the compiler, so no difference if it's register 2 or register 4
For more detailed read the avm specification
yep.. i second it. changing the name length is not gonna help you. concentrate on item renderers, effects, states and transitions. those may be killing your resource. also checkout for any embedding images, embedding fonts, etc, since those will increase ur final swf file size and increase initial loading time.
cheers, PK
I don't think so, the way you use your variable name does matter than its length.
Good code should be consistent. Whether that means setting rules for the names of variables and functions, adopting standard approaches, or simply making sure all of your code is indented the same way, consistency makes your code easier for others to read.
One should later construe on what is your variable name declared.
var g:String;
var gang:String;
Both perform the same operation, one is more readability where someone going through your code will also construe it.
There's a very small performance gain, but if you plan to use this application again later, it's not worth your sanity. Do absolutely any other optimization you can before this one - and if it's really slow enough to need optimizing, then there are definitely other factors that you'll need to take care of first before variable names.
Cut anything else you can before resorting to 1-2 millisecond boosts.
As Matchu says, there is a difference but a small one.
You should consider assigning meaningful ids to your variables instead of just using simple chars which have no sense.
Related
I'm starting to use RWMutex in my Go project with map since now I have more than one routine running at the same time and while making all of the changes for that a doubt came to my mind.
The thing is that I know that we must use RLock when only reading to allow other routines to do the same task and Lock when writing to full-block the map. But what are we supposed to do when editing a previously created element in the map?
For example... Let's say I have a map[int]string where I do Lock, put inside "hello " and then Unlock. What if I want to add "world" to it? Should I do Lock or can I do RLock?
You should approach the problem from another angle.
A simple rule of thumb you seem to understand just fine is
You need to protect the map from concurrent accesses when at least one of them is a modification.
Now the real question is what constitutes a modification of a map.
To answer it properly, it helps to notice that values stored in maps are not addressable — by design.
This was engineered that way simply due to the fact maps internally have intricate implementation which
might move values they contain in memory
to provide (amortized) fast access time
when the map's structure changes due to insertions and/or deletions of its elements.
The fact map values are not addressable means you can not do
something like
m := make(map[int]string)
m[42] = "hello"
go mutate(&m[42]) // take a single element and go modifying it...
// ...while other parts of the program change _other_ values
m[123] = "blah blah"
The reason you are not allowed to do this is the
insertion operation m[123] = ... might trigger moving
the storage of the map's element around, and that might
involve moving the storage of the element keyed by 42
to some other place in memory — pulling the rug
from under the feet of the goroutine
running the mutate function.
So, in Go, maps really only support three operations:
Insert — or replace — an element;
Read an element;
Delete an element.
You cannot modify an element "in place" — you can only
go in three steps:
Read the element;
Modify the variable containing the (read) copy;
Replace the element by the modified copy.
As you can now see, the steps (1) and (3) are mere map accesses,
and so the answer to your question is (hopefully) apparent:
the step (1) shall be done under at least an read lock,
and the step (3) shall be done under a write (exclusive) lock.
In contrast, elements of other compound types —
arrays (and slices) and fields of struct types —
do not have the restriction maps have: provided the storage
of the "enclosing" variable is not relocated, it is fine to
change its different elements concurrently by different goroutines.
Since the only way to change the value associated with the key in the map is to reassign the changed value to the same key, that is a write / modification, so you have to obtain the write lock–simply using the read lock will not be sufficient.
I see a lot of functional programming related topics mention destructive updates. I understand that it is something similar to mutation, so I understand the update part. But what is the destructive part? Or am I just over-thinking it?
You're probably overthinking it a bit. Mutability is all there is to it; the only thing being "destroyed" is the previous value of whatever you mutated.
Say you're using some sort of search tree to store values, and you want to insert a new one. After finding the location where the new values goes, you have two options:
With an immutable tree, you construct new nodes along the path from the new value's location up to the root. Subtrees not along the path are reused in the new tree, and if you still have a reference to the original tree's root you can use both, with the common subtrees shared between them. This economizes on space with no extra effort if you have lots of slightly-different copies floating around, and of course you have all the usual benefits of immutable data structures.
With a mutable tree, you attach the new value where it belongs and that's that; nothing else has to be changed. This is almost always faster, and economizes on memory allocation if you only ever have one copy around, but anything that had a reference to the "old" tree now has a reference to the new one. The original has been destroyed; it's gone forever. If you need to keep the original around, you have to go to the expense of creating an entirely new copy of the whole thing before changing it.
If "destruction" seems an unnecessarily harsh way to describe a simple in-place update, then you've probably not spent as much time as I have debugging code in order to figure out where on Earth some value is being changed behind your back.
The imperative programming languages allow variables to be redefined, e.g
x = 1
x = 2
So x first has the value 1 then, later, it has the value 2. The second operation is an destructive update, because x looses its initial definition as being equal to 1.
This is not how definition is handled in common mathematics. Once defined, a variable keeps its value.
The above, seen as system of equations, would allow to subtract the first from the second equation, which would give
x - x = 2 - 1 <=> 0 = 1
which is a false statement. It is assumed that once introduced, x is the same.
A familiar statement like
x = x + 1
would lead to the same conclusion.
The functional languages have the same use of variables, once they are defined it is not possible to reassign them. The above statement would turn into
x2 = x + 1
and we would have no for or while loop but rather recursion or some higher order function.
IDE - Visual Studio 2008, Visual C++
I have a custom class Class1 with a copy constructor to it.
I also have a vector
Data is inserted using the following code
Class1* objClass1;
vector<Class1> vClass1;
for(int i=0;i<1000;i++) {
objClass1 = new Class1();
vClass1.push_back(*objClass1);
delete objClass1;
}
Now on every insert, the vector gets re-allocated and all the existing contents are copied to new locations. For example, if the vector has 5 elements and if I insert the 6th one, the previous 5 elements along with the new one gets copied to a new location (I figured it out by adding log statements in the copy constructors.)
On using reserve(), this however does not happen as expected! I have the following questions
Is it mandatory to always use the reserve statement?
Does vector does a reallocation every time I do a push_back; or does it happen because I am debugging?
It's not mandatory, it's an optimization because reallocating is expensive.
I think it's an implementation detail how often it reallocates. I think it's normal for the vector to double its storage every time it reallocates, but, as I said, this can vary by implementation. (It might be the case that because you are in a debug build it's reallocating more often than normal.)
Find out by putting your copy constructor test into non debug code, and let us know what you get for your platform! IMO the vector shouldn't reallocate on every pushback. There are smarter ways to manage memory, and I'd bet money that the implementers didn't do that.
I have the feeling that I should not care about thread safe accessing / writing to an
public static int MyVar = 12;
in ASP .NET.
I read/write to this variable from various user threads. Let's suppose this variable will store the numbers of clicks on a certain button/link.
My theory is that no thread can read/write to this variable at the same time. It's just a simple variable of 4 bytes.
I do care about thread safe, but only for refference objects and List instances or other types that take more cycles to read/update.
I am wrong with my presumption ?
EDIT
I understand this depend of my scenario, but wasn't that the point of the question. The question is: it is right that can be written thread safe code with an (static int) variable without using lock keyword ?
It is my problem to write correct code. The answer seems to be: Yes, if you write correct and simple code, and not to much complicated, you can create thread safe functions without the need of lock keyword.
If one thread simply sets the value and another thread reads the value, then a lock is not necessary; the read and write are atomic. But if multiple threads might be updating it and are also reading it to do the update (e.g., increment), then you definitely do need some kind of synchronization. If only one thread is ever going to update it even for an increment, then I would argue that no synchronization is necessary.
Edit (three years later) It might also be desirable to add the volatile keyword to the declaration to ensure that reads of the value always get the latest value (assuming that matters in the application).
The concept of thread 'safety' is too vague to be meaningful unfortunately. If you're asking whether you can read and write to it from multiple threads without the program crashing during the operation, the answer is almost certainly yes. If you're also asking if the variable is guaranteed to either be the old value or the new value without ever storing any broken intermediate values, the answer for this data type is again almost certainly yes.
But if your question is "will my program work correctly if I access this from multiple threads", then the answer depends entirely on what your program is doing. For example, if you run the following pseudo code in 2 threads repeatedly in most programming languages, eventually you'll hit the assertion.
if MyVar >= 1:
MyVar = MyVar - 1
assert MyVar >= 0
Primitives like int are thread-safe in the sense that reads/writes are atomic. But as with most any type, it's left to you to do proper checking with more complex operations. For example, if (x > 0) x--; would be problematic in a multi-threaded scenario because x might change in between the if condition check and decrement.
A simple read or write on a field of 32 bits or less is always atomic. But you should provide your read/write code to make sure that it is thread safe.
Check out this post: http://msdn.microsoft.com/en-us/magazine/cc163929.aspx
It explains why you need to synchronize access to the integers in this scenario
Try Interlocked.Increment() or Interlocked.Add() and you'll be right. Your code complexity will be the same but you truly won't have to worry. If you're not worried about losing a few clicks in your counter, you can continue as you are.
Reading or writing integers is atomic. However, reading and then writing is not atomic. So, if you have one thread that writes and many that read, you may be able to get away without locks.
However, even though the operations are atomic, there are still potential multi-threading issues. In order for one thread to be guaranteed that another thread can see values it writes, you need a memory barrier. Otherwise, the compiler can optimize the code so that the variable stays in a register (or even optimize the operation away completely), so changes would be invisible from one thread to another.
You can establish a memory barrier explicitly (volatile or Thread.MemoryBarrier), or with the Interlocked class -- or with the lock statement (Monitor).
From using a number of programming languages and libraries I have noticed various terms used for the total number of elements in a collection.
The most common seem to be length, count, and size.
eg.
array.length
vector.size()
collection.count
Is there any preferred term to be used?
Does it depend on what type of collection it is? ie. mutable/immutable
Is there a preference for it being a property instead of a method?
Length() tends to refer to contiguous elements - a string has a length for example.
Count() tends to refer to the number of elements in a looser collection.
Size() tends to refer to the size of the collection, often this can be different from the length in cases like vectors (or strings), there may be 10 characters in a string, but storage is reserved for 20. It also may refer to number of elements - check source/documentation.
Capacity() - used to specifically refer to allocated space in collection and not number of valid elements in it. If type has both "capacity" and "size" defined then "size" usually refers to number of actual elements.
I think the main point is down to human language and idioms, the size of a string doesn't seem very obvious, whilst the length of a set is equally confusing even though they might be used to refer to the same thing (number of elements) in a collection of data.
FWIW (and that's vanishingly close to nothing), I prefer 'Count' because it seems to indicate that it's going to return the number of elements/items in the collection pretty unambigously.
When faced with the terms 'Length' or 'Size' I'm often left wondering for a moment (or even being forced to re-read documentation) whether the damn thing is going to tell me how many elements are in the colection or how many bytes the collection is consuming. This is particularly true for collections that are intended to be contingous like arrays or strings.
But no one who was responsible for the naming conventions used by the Java, BCL/.Net, or C/C++ standard frameworks/libraries bothered to ask me, so you're all stuck with whatever they came up with.
If only I were much smarter than I am and was named Bjarne, all of you might be spared the misery...
Of course, back in the real world, you should try to stick with whatever naming convention is used by the language/platform you're using (eg., size() in C++). Not that this seems to help you with your Array.Length dilemma.
The terms are somewhat interchangeably, though in some situations I would prefer one over another. Usually you can get the best usage if you think about How would you describe the length/size/count of this element verbally to another person?
length() implies that the element has a length. A string has a length. You say "a string is 20 characters long", right? So it has a length.
size() implies that the element has a size. E.g. a file has a size. You say "this file has a size of 2 MB", right? So it has a size.
That said, a string can also have a size, but I'd expect something else here. E.g. a UTF-16 string may have a length of 100 characters, but as every character is composed out of two byte, I'd expect size to be 200.
count() is very unusual. Objective-C uses count for the number of elements in an array. One might argue if an array has a length (as in Java), has a size (as in most other languages) or has a count. However, size might again be the size in byte (if the array items are 32 bit int, each item is 4 byte) and length... I wouldn't say "an array is 20 elements long", that sounds rather odd to me. I'd say "an array has 20 elements". I'm not sure if count expresses that very well, but I think count is here a short form for elementCount() and that again makes much more sense for an array than length() or size().
If you create own objects/elements in a programming language, it's best to use whatever other similar elements use, since programmers are used to accessing the desired property using that term.
Count I think is the most obvious term to use if you're looking for the number of items in a collection. That should even be obvious to new programmers who haven't become particularly attached to a given language yet.
And it should be a property as that's what it is: a description (aka property) of the collection. A method would imply that it has to do something to the collection to get the number of items and that just seems unintuitive.
Hmm...I would not use size. Because this might be confused with size in bytes.
Length - could make some sense for arrays, as long as they are supposed to use consequent bytes of memory.
Though...length...in what?
Count is clear. How many elements. I would use count.
About property/method, I would use property to mark it's fast, and method to mark it's slow.
And, the most important - I would stick to the standards of the languages/libraries you are using.
Adding to #gbjbaanb's answer...
If "property" implies public access to the value, I would say that "method" is preferred simply to provide encapsulation and to hide the implementation.
You might change you mind about how to count elements or how you maintain that count. If it is a property, you're stuck - if it is acessed via a method, you can change the underlying implementation without impacting users of the collection.
Kotlin answer
from _Collections.kt
/**
* Returns the number of elements in this collection.
*/
#kotlin.internal.InlineOnly
public inline fun <T> Collection<T>.count(): Int {
return size
}
In Elixir there is actually a clear naming scheme associated with it across types in the language.
When “counting” the number of elements in a data structure, Elixir
also abides by a simple rule: the function is named size if the
operation is in constant time (i.e. the value is pre-calculated) or
length if the operation is linear (i.e. calculating the length gets
slower as the input grows).
To me, this is a little like asking whether "foreach" is better than "for each". It just depends on the language/framework.
I would say that it depends on particular language that you are using and classes. For example in c# if you are using Array you have Property Length, if you have something that inherits from IEnumerable you have extension Method Count(), but it is not fast. And if you inherited from ICollection you have Property Count.