Bug 23073

GemStone/S

6.7.2.1, 6.7.2, 6.7.1, 6.7, 6.6.5, 6.6.4, 6.6.3.3, 6.6.3.2, 6.6.3, 6.6.2, 6.6.1, 6.6, 6.5.8, 6.5.7.5, 6.5.7, 6.5.6, 6.5.5, 6.5.4, 6.5.2, 6.5.1, 6.5, 6.3.1, 6.3, 6.2.x, 6.2, 6.1.6, 6.1.5, 6.1.x, 6.0.x, 5.1.5.1, 5.1.5, 5.1.4

All

SharedDependencyList inefficiencies may cause performance issues

GemStone uses an internal structure under Globals called SharedDependencyList
(SDL), which is a hash dictionary using collision buckets containing dependency
lists (DLs). DLs are used to track indexing and other structures that need
to be updated whenever a particular object is modified.

The intention of the SDL is to reduce the total number of objects needed
to represent this information by allowing objects with the same DL to share
a common DL in the SDL, rather than each having its own DL. The actual
number of DLs in the SDL depends on the amount of sharing possible, but
in general, can be expressed as:

size(SDL) <= min(e, (2**n)-1)

where
  n = total number of indexed collections
  e = total number of elements contained in all indexed collections

There are certain cases where "extra" DLs may be left behind in the SDL.
Under extreme conditions, these additional DLs may cause performance problems
during index maintenance operations such as index creation and removal,
or updating of an index due to a change to an object participating in the
index. The following examples provide more information about these cases:

CASE 1

When you add an additional index to a collection, new DLs are generated
for those objects participating in the index, but older DLs are left behind.
This action repeats as additional indexes are added to a collection. Although
this action is unlikely to cause performance issues unless you have hundreds
of indexes on a single collection, it can cause the SDL to be larger than
expected. If the index is ever deleted, ALL of the DLs are removed, so
extra DLs never outlive their associated index collection.

CASE 2

If you have an index that has a String as a final path term, the DL generated
also includes a reference count to track how many other objects in indexed
collections reference the same String. As these objects add or remove references
to the shared String, a new DL is generated for each unique reference count
value. If this String is shared extensively, and the number of sharing
objects varies widely over time, then a very large number of extra DLs
could be generated, and may begin to affect performance. To avoid the possibility
of creating these extra DLs, we recommend:

  1. Avoid using shared Strings as path terms in indexed collections.
  2. Make such Strings invariant. Since invariant objects don't change,
     the system does not need to track dependency list information.
  3. In general, try to make objects in indexing paths invariant
     whenever possible.

Workaround

Follow the guidelines suggested above to reduce the likelihood of creating
large numbers of additional DLs.

If you find that you already have large numbers of DLs that are significantly
affecting your performance, there are steps that can be taken to removed
unneeded DLs. Contact GemStone Technical Support for more information.


                

Last updated: 5/10/14