DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480

[PATCH] Experimental performance improvements.





------- Additional Comments From [EMAIL PROTECTED]  2003-12-16 08:15 -------
The instances of java.util.BitSet that are created for each fo:element in 
PropSets are only used for collecting the properties of that element and the 
properties for all its child elements. The list of child-element properties are 
copied to the parent element by calling the mergeProperties() method repeatedly 
until no more properties can trickle upwards to the root element. (I really 
wanted to calculate the set of properties that can be applied to an element 
staticly by the .xsl instead, but I couldn't quite figure out how to du that).

As an example, the BitSet for an element without any child element consist of 
just the list of properties that apply to the element, while the BitSet for 
fo:root consists of all the properties from the xsl-fo specification.

After the completed BitSet's have been calculated, the BitSet are turned into a 
array of shorts by makeSpareIndices(). The array are always PROPERTY_COUNT long 
and only the slots with supported properties have a non-zero value.

For fo:root there is no packing, so all element "indices[n] = n".
For some other element that support 4 properties, ihe indices array might look 
like this:

   indices[0] = 5 // The number one properties that apply +1
   indices[2] = 1
   indices[10] = 2
   indices[142] = 3
   indices[202] = 4

where the rest of the array has 0 values. (It is important that all the 
property identifiers in Constants.java have non-zero values).

The short[] arrays (one for each element type) are stored in the static 
PropSets.mapping and can be retrieved by getPropertySet(elementId).
This method is called from the ctor of PropertyList().

The sparse indices array are then used as an extra level of indirection when 
accessing the PropertyList.values array.

All of this business with sparse indices and PropSets.jacva is only a memory 
optimization. Allocating a full array 
  values = new Property[PROPERTY_COUNT]
in PropertyList would work just as fine, but would use more memory.

Reply via email to