Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28610 > unrolled thread

where's your Vector, victor

Back to article view | Back to comp.lang.java.programmer

Contents

  where's your Vector, victor bob smith <bob@coolfone.net63.net> - 2014-05-30 01:11 -0700
    Re: where's your Vector, victor Josip Almasi <joe@vrspace.org> - 2014-05-30 12:45 +0200
      Re: where's your Vector, victor Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-30 08:06 -0400
      Re: where's your Vector, victor Robert Klemme <shortcutter@googlemail.com> - 2014-05-30 19:28 +0200
    Re: where's your Vector, victor Joerg Meier <joergmmeier@arcor.de> - 2014-05-30 12:58 +0200
    Re: where's your Vector, victor Knute Johnson <eternal@knutejohnson.com> - 2014-05-30 07:32 -0700
      Re: where's your Vector, victor Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-30 11:31 -0400
        Re: where's your Vector, victor Robert Klemme <shortcutter@googlemail.com> - 2014-05-30 19:30 +0200
        Re: where's your Vector, victor Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-05-31 00:30 +0300
          Re: where's your Vector, victor Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-30 18:23 -0400
            Re: where's your Vector, victor Robert Klemme <shortcutter@googlemail.com> - 2014-05-31 12:17 +0200
        Re: where's your Vector, victor leif.roar@invalid.com (Leif Roar Moldskred) - 2014-06-01 07:37 -0500
    Re: where's your Vector, victor Roedy Green <see_website@mindprod.com.invalid> - 2014-06-06 01:00 -0700

#28610 — where's your Vector, victor

I read that the Vector class is obsolete.

Can someone tell me in a nutshell why this is so?

Thank you.

[toc] | [next] | [standalone]

#28614

On 05/30/2014 10:11 AM, bob smith wrote:
> I read that the Vector class is obsolete.
>
> Can someone tell me in a nutshell why this is so?

Same as with Hashtable.
It's all synchronized, = slow.
And to make things worse, returned iterators are not synchronized:)
So, either pick some unsynchroized from java.util, or go to 
java.util.concurrent.

Regards...

[toc] | [prev] | [next] | [standalone]

#28617

On 5/30/2014 6:45 AM, Josip Almasi wrote:
> On 05/30/2014 10:11 AM, bob smith wrote:
>> I read that the Vector class is obsolete.
>>
>> Can someone tell me in a nutshell why this is so?
>
> Same as with Hashtable.
> It's all synchronized, = slow.
> And to make things worse, returned iterators are not synchronized:)

     One or the other of these arguments might be relevant, but
they can't both be relevant at the same time.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28621

On 30.05.2014 12:45, Josip Almasi wrote:
> On 05/30/2014 10:11 AM, bob smith wrote:
>> I read that the Vector class is obsolete.
>>
>> Can someone tell me in a nutshell why this is so?
>
> Same as with Hashtable.
> It's all synchronized, = slow.
> And to make things worse, returned iterators are not synchronized:)

This is not true.  java.util.Vector.Itr<E> does go through the same 
mutex as the Vector it is iterating.  But, as Jörg and others have 
noted, synchronizing all methods is not sufficient to ensure thread 
safety - especially not if multiple method calls must be executed 
atomically.  Then you still need an explicit synchronized block.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#28615

On Fri, 30 May 2014 01:11:48 -0700 (PDT), bob smith wrote:

> I read that the Vector class is obsolete.

> Can someone tell me in a nutshell why this is so?

Because ArrayList has the same capabilities without the pointless overhead
of the internal synchronization of Vector. Since it turned out that that
synchronization is not enough to make Vector thread-safe, there is no sane
reason to use it. The same is true for Hashtable: it has the overhead of
thread safety, but isn't really thread safe, so use HashMap instead.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28618

On 5/30/2014 01:11, bob smith wrote:
> I read that the Vector class is obsolete.
>
> Can someone tell me in a nutshell why this is so?
>
> Thank you.
>

Mostly mythology.  The Vector provides some additional functionality 
over a synchronized List but it's probably not something you will need. 
  If you don't need any synchronization then use an ArrayList, if you do 
the Vector will work fine too.

I use Vector every time I can just to send the big giant heads into a tizzy.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#28619

On 5/30/2014 10:32 AM, Knute Johnson wrote:
> On 5/30/2014 01:11, bob smith wrote:
>> I read that the Vector class is obsolete.
>>
>> Can someone tell me in a nutshell why this is so?
>>
>> Thank you.
>>
>
> Mostly mythology.  The Vector provides some additional functionality
> over a synchronized List but it's probably not something you will need.

     I'm "mostly" in agreement.  For curiosity's sake, though, I ran
a few simple timing tests and found that Vector took about 35% more
time than ArrayList (for the mix of operations I tried).

     "That's HU-U-U-GE!" somebody's shouting, but does it truly  make a
difference?  What else is the program doing, and how much time does it
spend on things other than List manipulation?  Like, say, constructing
the things that go into the Lists, ruminating about which Lists they
belong in, converting them to and from XML, ...?

     FWIW, the same tests also found that the List formed by applying
Collections.synchronizedList() to an ArrayList was about 5% slower
than Vector ...

>   If you don't need any synchronization then use an ArrayList, if you do
> the Vector will work fine too.
>
> I use Vector every time I can just to send the big giant heads into a
> tizzy.

     :)

     Also, there are a few API's in the core Java suite that still deal
in Vectors, particularly in Swing: DefaultComboBoxModel, JList, JTree, 
DefaultTableModel, ...

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28622

On 30.05.2014 17:31, Eric Sosman wrote:

>      Also, there are a few API's in the core Java suite that still deal
> in Vectors, particularly in Swing: DefaultComboBoxModel, JList, JTree,
> DefaultTableModel, ...

And OSGI - or did they dump Java 1 support by now?

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#28625

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

>     I'm "mostly" in agreement.  For curiosity's sake, though, I ran
> a few simple timing tests and found that Vector took about 35% more
> time than ArrayList (for the mix of operations I tried).
>     "That's HU-U-U-GE!" somebody's shouting, but does it truly  make a
> difference?  What else is the program doing, and how much time does it
> spend on things other than List manipulation?  Like, say, constructing

Well, even when the program is spending more time in other tasks, why
use a slow class when you can easily replace it with a faster one that
does the same thing?

And about the synchronization: in many cases, when you need
synchronization, you will need to synchronize something more than just
the Collection manipulation. And if the Collection handling is already
within a synchronized block, why use one more synchronization block
inside another one?

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#28626

On 5/30/2014 5:30 PM, Jukka Lahtinen wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>
>>      I'm "mostly" in agreement.  For curiosity's sake, though, I ran
>> a few simple timing tests and found that Vector took about 35% more
>> time than ArrayList (for the mix of operations I tried).
>>      "That's HU-U-U-GE!" somebody's shouting, but does it truly  make a
>> difference?  What else is the program doing, and how much time does it
>> spend on things other than List manipulation?  Like, say, constructing
>
> Well, even when the program is spending more time in other tasks, why
> use a slow class when you can easily replace it with a faster one that
> does the same thing?

     (Shrug.)  A friend of mine once referred to such micro-optimizations
as cleaning the cigarette butts and bottle tops off the beach so the
sand would be nice and clean around the beached whales.

     For new code I wouldn't use Vector (unless it's required by some
other API I can't control), but I wouldn't bother editing an old Vector-
using class simply to change it to ArrayList or something.  I'd need to
perform a *lot* of operations on the List to recoup the editing time.
Perhaps you're a faster typist?  ;)

> And about the synchronization: in many cases, when you need
> synchronization, you will need to synchronize something more than just
> the Collection manipulation. And if the Collection handling is already
> within a synchronized block, why use one more synchronization block
> inside another one?

     In a multi-threaded setting you need to pay close attention to
exactly which manipulations need to be atomic.  Vector or the Lists
produced by Collections.synchronizedList() will guarantee atomicity
for the individual method calls, but (as has been pointed out a few
times already) the program may require some combinations of those to
be atomic.  The classic example is iterating over the collection:
Just because .add() and .remove() and so on (and the Iterator methods
themselves) are atomic doesn't imply that the entire iteration is so.

     One approach, as you suggest, is to wrap the entire iteration
in a synchronized block:

	synchronized (theList) {
	    for (Thing t : theList) {
	       ...
	    }
	}

... and, as you say, any synchronization provided by theList itself
is pure overhead here: You could just as well use an unsynchronized
List of some kind.  But then you would have to ensure that every
*other* use of theList provided its own synchronization: You would
need to write

	synchronized (theList) {
	    theList.add(theThing);
	}

... and lie awake nights wondering whether you (or that dopey intern)
had forgotten the dance somewhere, or had accidentally synchronized on
the wrong thing.  I put it to you that you *would* use a synchronized
implementation for theList, even though the extra synchronization during
iteration would be overhead -- and with all that extra sleep, you'd be
in a better mood at breakfast.  :)

     Finally, I question the wisdom of a program design that requires
iterating over a collection shared by multiple threads.  You'll need to
hold the collection's lock for the entire iteration, including whatever
goes on inside the iterating loop, and it's a Bad Idea to hold locks
for "macroscopic" time.  I think this is what Josip Almasi was getting
at with "or go to java.util.concurrent" -- which usually involves more
than just dropping in a ConcurrentLinkedDeque or something, but requires
a fresh look at what the program really, truly needs to do.

     Back to the original question: Vector is disparaged for two main
reasons: It's slower than ArrayList, and it's not fashionable.  The
first reason is more often cited, but the latter probably has more
weight.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28628

On 31.05.2014 00:23, Eric Sosman wrote:
> On 5/30/2014 5:30 PM, Jukka Lahtinen wrote:

>> And about the synchronization: in many cases, when you need
>> synchronization, you will need to synchronize something more than just
>> the Collection manipulation. And if the Collection handling is already
>> within a synchronized block, why use one more synchronization block
>> inside another one?
>
>      In a multi-threaded setting you need to pay close attention to
> exactly which manipulations need to be atomic.  Vector or the Lists
> produced by Collections.synchronizedList() will guarantee atomicity
> for the individual method calls, but (as has been pointed out a few
> times already) the program may require some combinations of those to
> be atomic.  The classic example is iterating over the collection:
> Just because .add() and .remove() and so on (and the Iterator methods
> themselves) are atomic doesn't imply that the entire iteration is so.

>      Finally, I question the wisdom of a program design that requires
> iterating over a collection shared by multiple threads.

There is another effect of synchronization of all Vector methods which 
has not yet been quoted as far as I can see: because of the Java memory 
model every entry into and exit from a mutex forms a memory barrier 
which requires some synchronization (sorry for the term here) between 
thread local and global memory; it also permits some optimizations of 
the JRE with regard to reordering operations.  So even if each Vector 
instance is used only inside at most one thread and the overhead of 
synchronized in the usual simple tests where only a single instance is 
manipulated in a real world application the synchronization between 
local and global memory may actually have an adverse effect if many 
threads are doing a lot of state changes.  I would guess that the effect 
is even worse on NUMA architectures but I do not have enough insight to 
explore this further.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#28630

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> 
>     I'm "mostly" in agreement.  For curiosity's sake, though, I ran
> a few simple timing tests and found that Vector took about 35% more
> time than ArrayList (for the mix of operations I tried).
>

Yes, but optimizations in the JVMs has reduced the costs of
/synchronized/ significantly since the introduction of ArrayList.

Another difference between Vector and ArrayList is that Vector's
growth policy is specifically to grow with a specific size /n/,
whereas ArrayList's growth policy is left as an implementation
detail. For some use cases, this can be significant -- although
if it is, you should probably reconsider your whole approach.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28674

On Fri, 30 May 2014 01:11:48 -0700 (PDT), bob smith
<bob@coolfone.net63.net> wrote, quoted or indirectly quoted someone
who said :

>I read that the Vector class is obsolete.
>
>Can someone tell me in a nutshell why this is so?

it has built in thread safety which slows it down.  With ArrayList it
is optional. I believe either way it is faster.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
In former times, people who craved absolute power became gangsters.
Today, they become computer programmers.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web