hibernate-issues

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1789) HashMap initialization is very unefficient in cache hits

[<no...@at...>]

HashMap initialization is very unefficient in cache hits
--------------------------------------------------------

         Key: HHH-1789
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH=
-1789
     Project: Hibernate3
        Type: Improvement

 Environment: hibernate 3, db n/a
    Reporter: Aapo Kyr=C3=B6l=C3=A4


We have an entity which has a <map>-type of collection attached to it, that=
 uses <many-to-many> mapping. The map has cache setting of <cache usage=3D"=
nonstrict-read-write"/>=20

The problem is that the map is often quite large, 500-1000 elements in it. =
But when Hibernate3 instantiates it from cache (PersistentMap.initializeFro=
mCache()), it will create a HashMap with default parameters and then .put()=
 each item from the serialized cache data to the map.=20

HashMap default size is 16 and it resizes it to double always when it has 7=
5%*capacity elements in it. So, initializing a HashMap with 1000 entries wi=
ll cause 7 resizes (which are expensive): 16->32->64->128->256->512->1024->=
2048. This consumes a lot of memory and cpu because HashMap.resize() is a c=
ostly operation.=20

It would be better for Hibernate to initialize the map with loadfactor 1.0 =
and size of the cached serialized data array / 2 + some extra.=20



--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1789) improve efficiency of collection initialization from L2 cache hits

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1789?p=
age=3Dall ]

Steve Ebersole updated HHH-1789:
--------------------------------

      Component: core
        Summary: improve efficiency of collection initialization from L2 ca=
che hits  (was: HashMap initialization is very unefficient in cache hits)
    Fix Version: 3.2.0.cr3
      Assign To: Steve Ebersole
       Priority: Major

> improve efficiency of collection initialization from L2 cache hits
> ------------------------------------------------------------------
>
>          Key: HHH-1789
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/H=
HH-1789
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>  Environment: hibernate 3, db n/a
>     Reporter: Aapo Kyr=C3=B6l=C3=A4
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0.cr3

>
>
> We have an entity which has a <map>-type of collection attached to it, th=
at uses <many-to-many> mapping. The map has cache setting of <cache usage=
=3D"nonstrict-read-write"/>=20
> The problem is that the map is often quite large, 500-1000 elements in it=
. But when Hibernate3 instantiates it from cache (PersistentMap.initializeF=
romCache()), it will create a HashMap with default parameters and then .put=
() each item from the serialized cache data to the map.=20
> HashMap default size is 16 and it resizes it to double always when it has=
 75%*capacity elements in it. So, initializing a HashMap with 1000 entries =
will cause 7 resizes (which are expensive): 16->32->64->128->256->512->1024=
->2048. This consumes a lot of memory and cpu because HashMap.resize() is a=
 costly operation.=20
> It would be better for Hibernate to initialize the map with loadfactor 1.=
0 and size of the cached serialized data array / 2 + some extra.=20

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1789) improve efficiency of collection initialization from L2 cache hits

[Steve E. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1789?pa=
ge=3Dcomments#action_23537 ]=20

Steve Ebersole commented on HHH-1789:
-------------------------------------

Note this requires addition of method to both CollectionType and UserCollec=
tionType in the form:
public Object instantiate(int anticipatedSize);

> improve efficiency of collection initialization from L2 cache hits
> ------------------------------------------------------------------
>
>          Key: HHH-1789
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/H=
HH-1789
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>  Environment: hibernate 3, db n/a
>     Reporter: Aapo Kyr=C3=B6l=C3=A4
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0.cr3

>
>
> We have an entity which has a <map>-type of collection attached to it, th=
at uses <many-to-many> mapping. The map has cache setting of <cache usage=
=3D"nonstrict-read-write"/>=20
> The problem is that the map is often quite large, 500-1000 elements in it=
. But when Hibernate3 instantiates it from cache (PersistentMap.initializeF=
romCache()), it will create a HashMap with default parameters and then .put=
() each item from the serialized cache data to the map.=20
> HashMap default size is 16 and it resizes it to double always when it has=
 75%*capacity elements in it. So, initializing a HashMap with 1000 entries =
will cause 7 resizes (which are expensive): 16->32->64->128->256->512->1024=
->2048. This consumes a lot of memory and cpu because HashMap.resize() is a=
 costly operation.=20
> It would be better for Hibernate to initialize the map with loadfactor 1.=
0 and size of the cached serialized data array / 2 + some extra.=20

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1789) improve efficiency of collection initialization from L2 cache hits

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1789?p=
age=3Dall ]
    =20
Steve Ebersole resolved HHH-1789:
---------------------------------

    Resolution: Fixed

> improve efficiency of collection initialization from L2 cache hits
> ------------------------------------------------------------------
>
>          Key: HHH-1789
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/H=
HH-1789
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>  Environment: hibernate 3, db n/a
>     Reporter: Aapo Kyr=C3=B6l=C3=A4
>     Assignee: Steve Ebersole
>      Fix For: 3.2.0.cr3

>
>
> We have an entity which has a <map>-type of collection attached to it, th=
at uses <many-to-many> mapping. The map has cache setting of <cache usage=
=3D"nonstrict-read-write"/>=20
> The problem is that the map is often quite large, 500-1000 elements in it=
. But when Hibernate3 instantiates it from cache (PersistentMap.initializeF=
romCache()), it will create a HashMap with default parameters and then .put=
() each item from the serialized cache data to the map.=20
> HashMap default size is 16 and it resizes it to double always when it has=
 75%*capacity elements in it. So, initializing a HashMap with 1000 entries =
will cause 7 resizes (which are expensive): 16->32->64->128->256->512->1024=
->2048. This consumes a lot of memory and cpu because HashMap.resize() is a=
 costly operation.=20
> It would be better for Hibernate to initialize the map with loadfactor 1.=
0 and size of the cached serialized data array / 2 + some extra.=20

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators=
.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira