You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Robert Sfeir <ro...@codepuccino.com> on 2004/06/14 20:13:43 UTC

Vector use

I've been wondering about the use of Vector and Hashtable in OJB.  Are 
they there because we support older JDKs or is it because it's just 
what was there when OJB was first developed?  Vector and Hashtables are 
deprecated, and newer Collections are just more efficient.

I don't mind going through weeding them out, but if we intend to 
support JDK 1.2 and before then there is no sense in doing that.  Is 
there a large group of OJB users using JDK 1.2- ?

Thanks
R


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Robert Sfeir <ro...@codepuccino.com>.
On Jun 14, 2004, at 2:42 PM, Thomas Dudziak wrote:

> Robert Sfeir wrote:
>> I've been wondering about the use of Vector and Hashtable in OJB.  
>> Are they there because we support older JDKs or is it because it's 
>> just what was there when OJB was first developed?  Vector and 
>> Hashtables are deprecated, and newer Collections are just more 
>> efficient.
>
> Actually this is not true, they are not at all deprecated but rather 
> retrofitted into the new collection strategy

Yup see my other email correcting myself :-)

R


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Brian McCallister <mc...@forthillcompany.com>.
fwiw, there is a free (beer, not speech) version of jprobe available 
now. I don't know of anything else free which approaches the full 
version's abilities, but I haven't used the free version.

-Brian

On Jun 15, 2004, at 6:30 AM, Thomas Dudziak wrote:

> Ilkka Priha wrote:
>
>> Synchronization overhead is surprisingly low, at least with the 
>> newest Java VMs, in non-concurrent situations, but can cause 
>> bottlenecks in concurrent ones, which really slows down performance. 
>> On the other hand, if concurrency is expected, collections can't be 
>> substituted with non-synchronized classes without resolving the 
>> normal issues of thread-safety.
>>
>> As this topic has come up in almost all of our Java projects, we've 
>> made some simple benchmarks with ordered Integer objects to test 
>> (only) synchronization of collections. All collections have been 
>> constructed with enough space to hold the test objects (150% with 
>> maps) to avoid reallocation and rehashing. GC is called just before 
>> each test case.
>>
>> With integer based over-simplified hashcodes Hashtable and Vector 
>> perform actually better than the corresponding HashMap and ArrayList 
>> because their put, get and remove methods are somewhat simpler and 
>> call less internal methods. Synchronization of HashMap with 
>> Collections.syncronizedMap cause an overhead between 2-7 % depending 
>> on the operation. Synchronization of ArrayList with 
>> Collections.syncronizedList cause quite high relative overhead but 
>> it's only about 10 ns per call. Other benchmarks have shown that in 
>> more realistic hashing situations HashMap should perform better then 
>> Hashtable but probably because of better rehashing than missing 
>> synchronization.
>>
>> Sun JRE 1.4.2_004, Windows XP Pro, AMD Athlon XP 2400+, 1024 MB
>> ---------------------------------------------------------------
>> INFO [15/Jun/2004:08:03:20 +0000] Hashtable put 5000000 times:        
>>  1324
>> INFO [15/Jun/2004:08:03:20 +0000] Hashtable get 5000000 times:        
>>  468
>> INFO [15/Jun/2004:08:03:21 +0000] Hashtable remove 5000000 times:     
>> 452
>> INFO [15/Jun/2004:08:03:27 +0000] HashMap put 5000000 times:         
>> 3849
>> INFO [15/Jun/2004:08:03:29 +0000] HashMap get 5000000 times:         
>> 2508
>> INFO [15/Jun/2004:08:03:33 +0000] HashMap remove 5000000 times:     
>> 3397
>> INFO [15/Jun/2004:08:03:39 +0000] Synced HashMap put 5000000 times:   
>>   3942
>> INFO [15/Jun/2004:08:03:42 +0000] Synced HashMap get 5000000 times:   
>>   2680
>> INFO [15/Jun/2004:08:03:45 +0000] Synced HashMap remove 5000000 
>> times:     3459
>> INFO [15/Jun/2004:08:03:47 +0000] Vector add 5000000 times:         
>> 203
>> INFO [15/Jun/2004:08:03:47 +0000] Vector get 5000000 times:         
>> 171
>> INFO [15/Jun/2004:08:03:47 +0000] Vector remove 5000000 times:        
>>  156
>> INFO [15/Jun/2004:08:03:49 +0000] ArrayList add 5000000 times:        
>>  172
>> INFO [15/Jun/2004:08:03:49 +0000] ArrayList get 5000000 times:        
>>  187
>> INFO [15/Jun/2004:08:03:49 +0000] ArrayList remove 5000000 times:     
>> 171
>> INFO [15/Jun/2004:08:03:50 +0000] Synced ArrayList add 5000000 times: 
>>     218
>> INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList get 5000000 times: 
>>     234
>> INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList remove 5000000 
>> times: 530
>>
>> With multi-processor hardware the synchronization takes more time 
>> because the underlying mechanism is much more complicated. We've run 
>> benchmarks only in a two processor machine. Even there Hashtable 
>> performs better than HashMap, but Vector is now clearly slower than 
>> ArrayList (but still faster than synchronized ArrayList).
>>
>> Windows 2000 Server, 2 x Intel PIII 1266 MHz, 512 MB
>> ---------------------------------------------------------------------
>> INFO [15/Jun/2004:08:15:12 +0000] Hashtable put 5000000 times: 3172
>> INFO [15/Jun/2004:08:15:13 +0000] Hashtable get 5000000 times: 953
>> INFO [15/Jun/2004:08:15:14 +0000] Hashtable remove 5000000 times: 969
>> INFO [15/Jun/2004:08:15:22 +0000] HashMap put 5000000 times: 5813
>> INFO [15/Jun/2004:08:15:25 +0000] HashMap get 5000000 times: 2437
>> INFO [15/Jun/2004:08:15:28 +0000] HashMap remove 5000000 times: 3594
>> INFO [15/Jun/2004:08:15:37 +0000] Synced HashMap put 5000000 times: 
>> 6485
>> INFO [15/Jun/2004:08:15:40 +0000] Synced HashMap get 5000000 times: 
>> 2922
>> INFO [15/Jun/2004:08:15:44 +0000] Synced HashMap remove 5000000 
>> times: 4234
>> INFO [15/Jun/2004:08:15:47 +0000] Vector add 5000000 times: 688
>> INFO [15/Jun/2004:08:15:47 +0000] Vector get 5000000 times: 593
>> INFO [15/Jun/2004:08:15:48 +0000] Vector remove 5000000 times: 579
>> INFO [15/Jun/2004:08:15:51 +0000] ArrayList add 5000000 times: 313
>> INFO [15/Jun/2004:08:15:51 +0000] ArrayList get 5000000 times: 296
>> INFO [15/Jun/2004:08:15:51 +0000] ArrayList remove 5000000 times: 344
>> INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList add 5000000 times: 
>> 735
>> INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList get 5000000 times: 
>> 703
>> INFO [15/Jun/2004:08:15:55 +0000] Synced ArrayList remove 5000000 
>> times: 719
>>
>> -- Ilkka
>
> Pretty interesting stuff. I guess, some profiling is in order after 
> the 1.0 ;-)
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Thomas Dudziak <to...@first.fhg.de>.
Ilkka Priha wrote:

> Synchronization overhead is surprisingly low, at least with the newest 
> Java VMs, in non-concurrent situations, but can cause bottlenecks in 
> concurrent ones, which really slows down performance. On the other 
> hand, if concurrency is expected, collections can't be substituted 
> with non-synchronized classes without resolving the normal issues of 
> thread-safety.
>
> As this topic has come up in almost all of our Java projects, we've 
> made some simple benchmarks with ordered Integer objects to test 
> (only) synchronization of collections. All collections have been 
> constructed with enough space to hold the test objects (150% with 
> maps) to avoid reallocation and rehashing. GC is called just before 
> each test case.
>
> With integer based over-simplified hashcodes Hashtable and Vector 
> perform actually better than the corresponding HashMap and ArrayList 
> because their put, get and remove methods are somewhat simpler and 
> call less internal methods. Synchronization of HashMap with 
> Collections.syncronizedMap cause an overhead between 2-7 % depending 
> on the operation. Synchronization of ArrayList with 
> Collections.syncronizedList cause quite high relative overhead but 
> it's only about 10 ns per call. Other benchmarks have shown that in 
> more realistic hashing situations HashMap should perform better then 
> Hashtable but probably because of better rehashing than missing 
> synchronization.
>
> Sun JRE 1.4.2_004, Windows XP Pro, AMD Athlon XP 2400+, 1024 MB
> ---------------------------------------------------------------
> INFO [15/Jun/2004:08:03:20 +0000] Hashtable put 5000000 times:         
> 1324
> INFO [15/Jun/2004:08:03:20 +0000] Hashtable get 5000000 times:         
> 468
> INFO [15/Jun/2004:08:03:21 +0000] Hashtable remove 5000000 times:     452
> INFO [15/Jun/2004:08:03:27 +0000] HashMap put 5000000 times:         3849
> INFO [15/Jun/2004:08:03:29 +0000] HashMap get 5000000 times:         2508
> INFO [15/Jun/2004:08:03:33 +0000] HashMap remove 5000000 times:     3397
> INFO [15/Jun/2004:08:03:39 +0000] Synced HashMap put 5000000 
> times:     3942
> INFO [15/Jun/2004:08:03:42 +0000] Synced HashMap get 5000000 
> times:     2680
> INFO [15/Jun/2004:08:03:45 +0000] Synced HashMap remove 5000000 
> times:     3459
> INFO [15/Jun/2004:08:03:47 +0000] Vector add 5000000 times:         203
> INFO [15/Jun/2004:08:03:47 +0000] Vector get 5000000 times:         171
> INFO [15/Jun/2004:08:03:47 +0000] Vector remove 5000000 times:         
> 156
> INFO [15/Jun/2004:08:03:49 +0000] ArrayList add 5000000 times:         
> 172
> INFO [15/Jun/2004:08:03:49 +0000] ArrayList get 5000000 times:         
> 187
> INFO [15/Jun/2004:08:03:49 +0000] ArrayList remove 5000000 times:     171
> INFO [15/Jun/2004:08:03:50 +0000] Synced ArrayList add 5000000 
> times:     218
> INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList get 5000000 
> times:     234
> INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList remove 5000000 
> times: 530
>
> With multi-processor hardware the synchronization takes more time 
> because the underlying mechanism is much more complicated. We've run 
> benchmarks only in a two processor machine. Even there Hashtable 
> performs better than HashMap, but Vector is now clearly slower than 
> ArrayList (but still faster than synchronized ArrayList).
>
> Windows 2000 Server, 2 x Intel PIII 1266 MHz, 512 MB
> ---------------------------------------------------------------------
> INFO [15/Jun/2004:08:15:12 +0000] Hashtable put 5000000 times: 3172
> INFO [15/Jun/2004:08:15:13 +0000] Hashtable get 5000000 times: 953
> INFO [15/Jun/2004:08:15:14 +0000] Hashtable remove 5000000 times: 969
> INFO [15/Jun/2004:08:15:22 +0000] HashMap put 5000000 times: 5813
> INFO [15/Jun/2004:08:15:25 +0000] HashMap get 5000000 times: 2437
> INFO [15/Jun/2004:08:15:28 +0000] HashMap remove 5000000 times: 3594
> INFO [15/Jun/2004:08:15:37 +0000] Synced HashMap put 5000000 times: 6485
> INFO [15/Jun/2004:08:15:40 +0000] Synced HashMap get 5000000 times: 2922
> INFO [15/Jun/2004:08:15:44 +0000] Synced HashMap remove 5000000 times: 
> 4234
> INFO [15/Jun/2004:08:15:47 +0000] Vector add 5000000 times: 688
> INFO [15/Jun/2004:08:15:47 +0000] Vector get 5000000 times: 593
> INFO [15/Jun/2004:08:15:48 +0000] Vector remove 5000000 times: 579
> INFO [15/Jun/2004:08:15:51 +0000] ArrayList add 5000000 times: 313
> INFO [15/Jun/2004:08:15:51 +0000] ArrayList get 5000000 times: 296
> INFO [15/Jun/2004:08:15:51 +0000] ArrayList remove 5000000 times: 344
> INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList add 5000000 times: 735
> INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList get 5000000 times: 703
> INFO [15/Jun/2004:08:15:55 +0000] Synced ArrayList remove 5000000 
> times: 719
>
> -- Ilkka

Pretty interesting stuff. I guess, some profiling is in order after the 
1.0 ;-)

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Ilkka Priha <im...@surfeu.fi>.
Synchronization overhead is surprisingly low, at least with the newest Java VMs, 
in non-concurrent situations, but can cause bottlenecks in concurrent ones, 
which really slows down performance. On the other hand, if concurrency is 
expected, collections can't be substituted with non-synchronized classes without 
resolving the normal issues of thread-safety.

As this topic has come up in almost all of our Java projects, we've made some 
simple benchmarks with ordered Integer objects to test (only) synchronization of 
collections. All collections have been constructed with enough space to hold the 
test objects (150% with maps) to avoid reallocation and rehashing. GC is called 
just before each test case.

With integer based over-simplified hashcodes Hashtable and Vector perform 
actually better than the corresponding HashMap and ArrayList because their put, 
get and remove methods are somewhat simpler and call less internal methods. 
Synchronization of HashMap with Collections.syncronizedMap cause an overhead 
between 2-7 % depending on the operation. Synchronization of ArrayList with 
Collections.syncronizedList cause quite high relative overhead but it's only 
about 10 ns per call. Other benchmarks have shown that in more realistic hashing 
situations HashMap should perform better then Hashtable but probably because of 
better rehashing than missing synchronization.

Sun JRE 1.4.2_004, Windows XP Pro, AMD Athlon XP 2400+, 1024 MB
---------------------------------------------------------------
INFO [15/Jun/2004:08:03:20 +0000] Hashtable put 5000000 times: 		1324
INFO [15/Jun/2004:08:03:20 +0000] Hashtable get 5000000 times: 		468
INFO [15/Jun/2004:08:03:21 +0000] Hashtable remove 5000000 times: 	452
INFO [15/Jun/2004:08:03:27 +0000] HashMap put 5000000 times: 		3849
INFO [15/Jun/2004:08:03:29 +0000] HashMap get 5000000 times: 		2508
INFO [15/Jun/2004:08:03:33 +0000] HashMap remove 5000000 times: 	3397
INFO [15/Jun/2004:08:03:39 +0000] Synced HashMap put 5000000 times: 	3942
INFO [15/Jun/2004:08:03:42 +0000] Synced HashMap get 5000000 times: 	2680
INFO [15/Jun/2004:08:03:45 +0000] Synced HashMap remove 5000000 times: 	3459
INFO [15/Jun/2004:08:03:47 +0000] Vector add 5000000 times: 		203
INFO [15/Jun/2004:08:03:47 +0000] Vector get 5000000 times: 		171
INFO [15/Jun/2004:08:03:47 +0000] Vector remove 5000000 times: 		156
INFO [15/Jun/2004:08:03:49 +0000] ArrayList add 5000000 times: 		172
INFO [15/Jun/2004:08:03:49 +0000] ArrayList get 5000000 times: 		187
INFO [15/Jun/2004:08:03:49 +0000] ArrayList remove 5000000 times: 	171
INFO [15/Jun/2004:08:03:50 +0000] Synced ArrayList add 5000000 times: 	218
INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList get 5000000 times: 	234
INFO [15/Jun/2004:08:03:51 +0000] Synced ArrayList remove 5000000 times: 530

With multi-processor hardware the synchronization takes more time because the 
underlying mechanism is much more complicated. We've run benchmarks only in a 
two processor machine. Even there Hashtable performs better than HashMap, but 
Vector is now clearly slower than ArrayList (but still faster than synchronized 
ArrayList).

Windows 2000 Server, 2 x Intel PIII 1266 MHz, 512 MB
---------------------------------------------------------------------
INFO [15/Jun/2004:08:15:12 +0000] Hashtable put 5000000 times: 3172
INFO [15/Jun/2004:08:15:13 +0000] Hashtable get 5000000 times: 953
INFO [15/Jun/2004:08:15:14 +0000] Hashtable remove 5000000 times: 969
INFO [15/Jun/2004:08:15:22 +0000] HashMap put 5000000 times: 5813
INFO [15/Jun/2004:08:15:25 +0000] HashMap get 5000000 times: 2437
INFO [15/Jun/2004:08:15:28 +0000] HashMap remove 5000000 times: 3594
INFO [15/Jun/2004:08:15:37 +0000] Synced HashMap put 5000000 times: 6485
INFO [15/Jun/2004:08:15:40 +0000] Synced HashMap get 5000000 times: 2922
INFO [15/Jun/2004:08:15:44 +0000] Synced HashMap remove 5000000 times: 4234
INFO [15/Jun/2004:08:15:47 +0000] Vector add 5000000 times: 688
INFO [15/Jun/2004:08:15:47 +0000] Vector get 5000000 times: 593
INFO [15/Jun/2004:08:15:48 +0000] Vector remove 5000000 times: 579
INFO [15/Jun/2004:08:15:51 +0000] ArrayList add 5000000 times: 313
INFO [15/Jun/2004:08:15:51 +0000] ArrayList get 5000000 times: 296
INFO [15/Jun/2004:08:15:51 +0000] ArrayList remove 5000000 times: 344
INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList add 5000000 times: 735
INFO [15/Jun/2004:08:15:54 +0000] Synced ArrayList get 5000000 times: 703
INFO [15/Jun/2004:08:15:55 +0000] Synced ArrayList remove 5000000 times: 719

-- Ilkka


Thomas Dudziak wrote:
> Robert Sfeir wrote:
> 
>> I've been wondering about the use of Vector and Hashtable in OJB.  Are 
>> they there because we support older JDKs or is it because it's just 
>> what was there when OJB was first developed?  Vector and Hashtables 
>> are deprecated, and newer Collections are just more efficient.
> 
> 
> Actually this is not true, they are not at all deprecated but rather 
> retrofitted into the new collection strategy (implementing Map/List). 
> There are also subtle but important differences for instance between 
> Hashtable and HashMap: Hashtable is synchronized (possibly slower but 
> safer) and does not allow to use null as key. Vector is also 
> synchronized (unlike ArrayList) but the implementation can be faster 
> (depending on the JDK).
> 
>> I don't mind going through weeding them out, but if we intend to 
>> support JDK 1.2 and before then there is no sense in doing that.  Is 
>> there a large group of OJB users using JDK 1.2- ?
> 
> 
> I wouldn't move away from that because the more interesting classes were 
> introduced in 1.4 and a lot of people still use 1.3 JDKs/JREs.
> If there are spots were a replacement of Vector/Hashtable makes sense 
> (justified by performance measurements and with unit tests as 
> safety-net) then I'd rather replace them with commons-collections than 
> with JDK 1.4.
> 
> Tom
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> .
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Thomas Dudziak <to...@first.fhg.de>.
Robert Sfeir wrote:
> I've been wondering about the use of Vector and Hashtable in OJB.  Are 
> they there because we support older JDKs or is it because it's just what 
> was there when OJB was first developed?  Vector and Hashtables are 
> deprecated, and newer Collections are just more efficient.

Actually this is not true, they are not at all deprecated but rather 
retrofitted into the new collection strategy (implementing Map/List). 
There are also subtle but important differences for instance between 
Hashtable and HashMap: Hashtable is synchronized (possibly slower but 
safer) and does not allow to use null as key. Vector is also 
synchronized (unlike ArrayList) but the implementation can be faster 
(depending on the JDK).

> I don't mind going through weeding them out, but if we intend to support 
> JDK 1.2 and before then there is no sense in doing that.  Is there a 
> large group of OJB users using JDK 1.2- ?

I wouldn't move away from that because the more interesting classes were 
introduced in 1.4 and a lot of people still use 1.3 JDKs/JREs.
If there are spots were a replacement of Vector/Hashtable makes sense 
(justified by performance measurements and with unit tests as 
safety-net) then I'd rather replace them with commons-collections than 
with JDK 1.4.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Antonio Gallardo <ag...@agssa.net>.
Robert Sfeir dijo:
>Brian also knows
> I'm a performance freak, and pick at the little things.  So since I
> don't know OJB as well as everyone else does, and do what I can to
> contribute, I pick at performance analysis with the tools I currently
> have.

Maybe from my "old" school, where each milisec is important, I have the
same concerns! ;-)

> I've already suggested the use of final in a lot of places and ran some
> tests a while ago, and showed some serious drops in memory usage, but I
> think my patch was entirely too big for Brian to implement in one shot.
>
> I just want OJB to completely smoke the competition in performance :-)

We have the same target as the OJB team! :-D

Best Regards,

Antonio Gallardo.


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Thomas Dudziak <to...@first.fhg.de>.
Robert Sfeir wrote:

> The change of final I had made were in very specific spots and none of 
> them were to methods or classes.  Also yes, one of the reasons we SHOULD 
> be using it, is because this is open source and as such we should not 
> just blindly trust anyone making the changes, and this would give us an 
> edge over folks who might not be very careful on a change and at least 
> it will trip them up before the code is submitted.

Well, I'm not following you here. And in fact I fully agree with Sam 
(magpiebrain): I rather trust users to know what they are doing (and 
even more so in open source where everybody can see what is going on in 
the inside anyway). And if there is one thing that I've learned from 
creation and usage of frameworks, then that the places where the 
designer thinks that the user will change something (template & hook) 
are usually not the same places where users would like to (we had a 
couple of these, e.g. check archives for PersistentField and nested fields).

> That said the changes were to method parameters, instance variables 
> etc...  the intent is not to limit the extension of the api, rather make 
> sure a parameter/variable doesn't get unintentionally changed when it's 
> not supposed to, and help hint to the GC that it can toss them just as 
> soon as it can.

For internal stuff, then you're probably right though I guess a decent 
static code checker can find these too. As for the GC, well, I don't 
have enough knowledge about the internals of the VM to understand how 
the final keyword on a local variable would help the GC throwing 
variable values away earlier.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Robert Sfeir <ro...@codepuccino.com>.
>
> Please be careful with the use of final, though. There are several 
> reasons why *not* to use final in certain places (for instance see 
> here:
> http://www.magpiebrain.com/archives/2004/06/13/final), and especially 
> final APIs can become quite useless.

The change of final I had made were in very specific spots and none of 
them were to methods or classes.  Also yes, one of the reasons we 
SHOULD be using it, is because this is open source and as such we 
should not just blindly trust anyone making the changes, and this would 
give us an edge over folks who might not be very careful on a change 
and at least it will trip them up before the code is submitted.

That said the changes were to method parameters, instance variables 
etc...  the intent is not to limit the extension of the api, rather 
make sure a parameter/variable doesn't get unintentionally changed when 
it's not supposed to, and help hint to the GC that it can toss them 
just as soon as it can.

R


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Thomas Dudziak <to...@first.fhg.de>.
Robert Sfeir wrote:
> k.  Just getting an opinion before I pick through things.  I think we 
> should DEFINITELY profile OJB after 1.0.  I don't intend to make any of 
> these changes right now.  I've already told Brian that I think there are 
> a few things that can be done, including removing Tail Recursions where 
> possible for example, to improve performance.  Brian also knows I'm a 
> performance freak, and pick at the little things.  So since I don't know 
> OJB as well as everyone else does, and do what I can to contribute, I 
> pick at performance analysis with the tools I currently have.

Definitly a +1 both because of the (hopefully) great performance boost 
and the lots of new unit tests ;-)
BTW, what performance tools do you use ? Have you used Hyades ? I would 
be interested to hear how that one compares.

> I've already suggested the use of final in a lot of places and ran some 
> tests a while ago, and showed some serious drops in memory usage, but I 
> think my patch was entirely too big for Brian to implement in one shot.

Please be careful with the use of final, though. There are several 
reasons why *not* to use final in certain places (for instance see here:
http://www.magpiebrain.com/archives/2004/06/13/final), and especially 
final APIs can become quite useless.

> I just want OJB to completely smoke the competition in performance :-) 

Again +2 !

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Robert Sfeir <ro...@codepuccino.com>.
k.  Just getting an opinion before I pick through things.  I think we 
should DEFINITELY profile OJB after 1.0.  I don't intend to make any of 
these changes right now.  I've already told Brian that I think there 
are a few things that can be done, including removing Tail Recursions 
where possible for example, to improve performance.  Brian also knows 
I'm a performance freak, and pick at the little things.  So since I 
don't know OJB as well as everyone else does, and do what I can to 
contribute, I pick at performance analysis with the tools I currently 
have.

I've already suggested the use of final in a lot of places and ran some 
tests a while ago, and showed some serious drops in memory usage, but I 
think my patch was entirely too big for Brian to implement in one shot.

I just want OJB to completely smoke the competition in performance :-)

Thanks
R

On Jun 14, 2004, at 3:01 PM, Thomas Dudziak wrote:

> Robert Sfeir wrote:
>
>> I guess what bugs me the most about Vector is that it's synchronized, 
>> and while I am not extremely familiar with the code, there are some 
>> spots which look like we don't need synchronization, and we could 
>> benefit from the added performance.
>> The other thing is that since Vector has been retrofitted to 
>> implement Collection, when we have a line like:
>> private Vector foo = new Vector();
>> wouldn't it be better to use something like:
>> private List foo = new Vector();
>> or
>> private Collection foo = new Vector();
>> (Depending on the purpose of course being listed v/s non 
>> discriminatory)
>> which should allow us to support people using 1.2 + in any case, then 
>> we can change our implementation underneath as we go forward and not 
>> affect the code.  We can apply changes to the impl as we properly 
>> determine sync need v/s none, and choose a better Collection when we 
>> see the need.
>> Thoughts?
>>
>
> To be completely honest with you, usage of Vector and Hashtable 
> doesn't really bug me. Of course we can replace them as we change code 
> for some other reason, but hunting them does not seem worthwile to me 
> if there is no real incentive for it (e.g. a big performance boost 
> because a vector is used in a core spot where an array list would be 
> faster). How about profiling OJB after the 1.0 is out ?
> Also I have a somewhat uneasy feeling about declaring a variable with 
> one type and initializing it with another type when this is the only 
> type that the actual value will ever have. I personally prefer to be 
> as precise as possible about the (possible) types of a value. IMO we 
> should use the interfaces explicitly only for public or protected 
> features.
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Thomas Dudziak <to...@first.fhg.de>.
Robert Sfeir wrote:

> I guess what bugs me the most about Vector is that it's synchronized, 
> and while I am not extremely familiar with the code, there are some 
> spots which look like we don't need synchronization, and we could 
> benefit from the added performance.
> 
> The other thing is that since Vector has been retrofitted to implement 
> Collection, when we have a line like:
> 
> private Vector foo = new Vector();
> 
> wouldn't it be better to use something like:
> 
> private List foo = new Vector();
> or
> private Collection foo = new Vector();
> 
> (Depending on the purpose of course being listed v/s non discriminatory)
> 
> which should allow us to support people using 1.2 + in any case, then we 
> can change our implementation underneath as we go forward and not affect 
> the code.  We can apply changes to the impl as we properly determine 
> sync need v/s none, and choose a better Collection when we see the need.
> 
> Thoughts?
>

To be completely honest with you, usage of Vector and Hashtable doesn't 
really bug me. Of course we can replace them as we change code for some 
other reason, but hunting them does not seem worthwile to me if there is 
no real incentive for it (e.g. a big performance boost because a vector 
is used in a core spot where an array list would be faster). How about 
profiling OJB after the 1.0 is out ?
Also I have a somewhat uneasy feeling about declaring a variable with 
one type and initializing it with another type when this is the only 
type that the actual value will ever have. I personally prefer to be as 
precise as possible about the (possible) types of a value. IMO we should 
use the interfaces explicitly only for public or protected features.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Robert Sfeir <ro...@codepuccino.com>.
I guess what bugs me the most about Vector is that it's synchronized, 
and while I am not extremely familiar with the code, there are some 
spots which look like we don't need synchronization, and we could 
benefit from the added performance.

The other thing is that since Vector has been retrofitted to implement 
Collection, when we have a line like:

private Vector foo = new Vector();

wouldn't it be better to use something like:

private List foo = new Vector();
or
private Collection foo = new Vector();

(Depending on the purpose of course being listed v/s non discriminatory)

which should allow us to support people using 1.2 + in any case, then 
we can change our implementation underneath as we go forward and not 
affect the code.  We can apply changes to the impl as we properly 
determine sync need v/s none, and choose a better Collection when we 
see the need.

Thoughts?

R

On Jun 14, 2004, at 2:23 PM, Antonio Gallardo wrote:

> Robert Sfeir dijo:
>> I've been wondering about the use of Vector and Hashtable in OJB.  Are
>> they there because we support older JDKs or is it because it's just
>> what was there when OJB was first developed?  Vector and Hashtables 
>> are
>> deprecated, and newer Collections are just more efficient.
>>
>> I don't mind going through weeding them out, but if we intend to
>> support JDK 1.2 and before then there is no sense in doing that.  Is
>> there a large group of OJB users using JDK 1.2- ?
>
> I think today no one is using java 1.2 (correct me if I am wrong). As 
> you
> pointed before, it is because historic reasons. Perhaps we can change 
> to
> collections onces we release the 1.0.
>
> We can set J2SDK 1.3 as the minimum requirement for OJB 1.1 and later.
> That way we can switch to collections. Also there are a lot of 
> interesting
> classes in commons-collections and we can take advantage of them!
>
> WDYT?
>
> BTW, I am waiting for the end of the month to receive this interesting 
> book:
>
> Pro Jakarta Commons by Harshad Oak, ISBN: 1590592832
> http://www.amazon.com/exec/obidos/tg/detail/-/1590592832/
>
> I hope this book will be very interesting one.
>
> Best Regards,
>
> Antonio Gallardo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Antonio Gallardo <ag...@agssa.net>.
Robert Sfeir dijo:
> I've been wondering about the use of Vector and Hashtable in OJB.  Are
> they there because we support older JDKs or is it because it's just
> what was there when OJB was first developed?  Vector and Hashtables are
> deprecated, and newer Collections are just more efficient.
>
> I don't mind going through weeding them out, but if we intend to
> support JDK 1.2 and before then there is no sense in doing that.  Is
> there a large group of OJB users using JDK 1.2- ?

I think today no one is using java 1.2 (correct me if I am wrong). As you
pointed before, it is because historic reasons. Perhaps we can change to
collections onces we release the 1.0.

We can set J2SDK 1.3 as the minimum requirement for OJB 1.1 and later.
That way we can switch to collections. Also there are a lot of interesting
classes in commons-collections and we can take advantage of them!

WDYT?

BTW, I am waiting for the end of the month to receive this interesting book:

Pro Jakarta Commons by Harshad Oak, ISBN: 1590592832
http://www.amazon.com/exec/obidos/tg/detail/-/1590592832/

I hope this book will be very interesting one.

Best Regards,

Antonio Gallardo


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Re: Vector use

Posted by Robert Sfeir <ro...@codepuccino.com>.
I mean kind of obsolete not deprecated... fumbling my words sorry.

R

On Jun 14, 2004, at 2:13 PM, Robert Sfeir wrote:

> I've been wondering about the use of Vector and Hashtable in OJB.  Are 
> they there because we support older JDKs or is it because it's just 
> what was there when OJB was first developed?  Vector and Hashtables 
> are deprecated, and newer Collections are just more efficient.
>
> I don't mind going through weeding them out, but if we intend to 
> support JDK 1.2 and before then there is no sense in doing that.  Is 
> there a large group of OJB users using JDK 1.2- ?
>
> Thanks
> R
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org