-
Notifications
You must be signed in to change notification settings - Fork 57
Expand file tree
/
Copy pathWhich is faster?
More file actions
52 lines (40 loc) · 2.87 KB
/
Which is faster?
File metadata and controls
52 lines (40 loc) · 2.87 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Question: Among StringBuilder and StringBuffer, which is faster and why?
Ans: StringBuilder, because it is not synchronized hence no synchronization overhead and hence it is faster
than StringBuffer.StringBuffer is thread-safe and hence contains synchronized methods and hence the overhead
and therefore slower in execution than StringBuilder.
Question: Which is faster, ArrayList or Vector and why?
Ans: ArrayList, because it is not synchronized hence no synchronization overhead and hence it is faster
than Vector. Vector is thread-safe and hence contains synchronized methods and hence the overhead
and therefore slower in execution than ArrayList.
Question: Which is faster, Hashtable/HashMap OR Vector?
Ans: Hashtable/HashMap, because it is not synchronized hence no synchronization overhead and hence it is faster
than Vector. Vector is thread-safe and hence contains synchronized methods and hence the overhead
and therefore slower in execution than Hashtable/HashMap.
Question: Are Synchronized Methods Slower In Single Threaded Applications also?
Source: http://stackoverflow.com/questions/973518/are-synchronized-methods-slower-in-single-threaded-applications
Ans: Yes, single-theaded Java programs that use synchronization may be slightly slower than they
would be without synchronization. For early Java releases, synchronization was expensive.
For any modern release, however, uncontended synchronization is pretty cheap. I wouldn't worry about this.
Note that Java 6 has and Java 7 is to have good optimizations around locking:
Lock coarsening
Lock elision
Adaptive Spin locking
Biased locking
For more information, see the Java SE 6 Performance White Paper.
Also note that uncontended synchronization appears to be more expensive on multi-core CPUs than
on single-core CPUs, perhaps due to the Java Memory Model requirements of synchronization forcing local
CPU caches to be shared with other CPUs, or some other memory barrier.
For example,
read Do Java 6 threading optimizations actually work? - Part II.
(The Part I was not as insightful as the Part II.)
Question: Why are synchronized methods said to be comparitively slow to non-synchronized methods in java?
Ans:
Source: http://stackoverflow.com/questions/1671089/why-are-synchronize-expensive-in-java
It is expensive because if you are using threads, and a number of threads have to go through a
synchronized section of code, only one of them may be executed at a time.
It is like a bottleneck.
It is even expensive when you use a single thread, because it has to check anyway if he is allowed to run.
(Related Question: Are Synchronized Methods Slower In Single Threaded Applications also?
Answer: Yes, explained in the line above this line and in the previous question as well. Have a look.
If you reduce the use of synchronized segments your thread won't have to stop to see if they can run
( of course, they don't have to share data )