RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity
Hi, It would be useful to have a Properties constructor that takes an argument to set the initial capacity. Such a constructor is present on many of the other Map implementations in the JDK, including Hashtable, the superclass of Properties. In particular, being able to specify the initial capacity of the Properties object created to store the system properties could reduce startup time. The current initial capacity of 8 is insufficient. We could eliminate ~25,000 bytecodes currently spent resizing the Properties by creating one of sufficient initial size. There are ~60 system properties in a minimal Java app. I chose 84 - it provides a good amount of wiggle room (and results in an internal ConcurrentHashMap with a table size of 128; 64 would be too small, IMO). Please review this change: Issue: https://bugs.openjdk.java.net/browse/JDK-8189319 Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/ Thanks, -Brent
On 10/26/17 6:43 PM, Brent Christian wrote:
Hi,
It would be useful to have a Properties constructor that takes an argument to set the initial capacity. Such a constructor is present on many of the other Map implementations in the JDK, including Hashtable, the superclass of Properties.
In particular, being able to specify the initial capacity of the Properties object created to store the system properties could reduce startup time. The current initial capacity of 8 is insufficient. We could eliminate ~25,000 bytecodes currently spent resizing the Properties by creating one of sufficient initial size.
There are ~60 system properties in a minimal Java app. I chose 84 - it provides a good amount of wiggle room (and results in an internal ConcurrentHashMap with a table size of 128; 64 would be too small, IMO).
Please review this change:
Issue: https://bugs.openjdk.java.net/browse/JDK-8189319 Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/
Looks okay. It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity. Mandy
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html Thanks, -Brent
On 10/27/17 2:37 PM, Brent Christian wrote:
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new webrev:
http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html
Looks good. Mandy
+1 On 10/27/17 5:39 PM, mandy chung wrote:
On 10/27/17 2:37 PM, Brent Christian wrote:
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new webrev:
http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html
Looks good.
Mandy
Thank you for the reviews! -Brent
I completely missed the fact that Properties continues to inherit from Hashtable but the data is actually stored in a CHM. I would have been afraid to make that change ... Looks good! On Thu, Oct 26, 2017 at 6:43 PM, Brent Christian <brent.christian@oracle.com
wrote:
Hi,
It would be useful to have a Properties constructor that takes an argument to set the initial capacity. Such a constructor is present on many of the other Map implementations in the JDK, including Hashtable, the superclass of Properties.
In particular, being able to specify the initial capacity of the Properties object created to store the system properties could reduce startup time. The current initial capacity of 8 is insufficient. We could eliminate ~25,000 bytecodes currently spent resizing the Properties by creating one of sufficient initial size.
There are ~60 system properties in a minimal Java app. I chose 84 - it provides a good amount of wiggle room (and results in an internal ConcurrentHashMap with a table size of 128; 64 would be too small, IMO).
Please review this change:
Issue: https://bugs.openjdk.java.net/browse/JDK-8189319 Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/
Thanks, -Brent
participants (4)
-
Brent Christian
-
mandy chung
-
Martin Buchholz
-
Roger Riggs