[Bug 25480] - [PATCH] Experimental performance improvements.

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
>
> ------- Additional Comments From glenmazza@yahoo.com  2004-01-10


Glen / Finn,

Hope you don't mind my interrupting here:

Particularly this point I found interesting:

> 3.) PropertySets.java defines those properties which are valid
> for each FO--in PropertyList, the proposed implementation then uses that
> information to limit the properties that can be assigned to an FObj
> (i.e., only those defined as valid for it.)  Am I correct here on this
point?
>
> If so, we may need to expand the "valid" properties to include
> the inheritable ones.
>
<snip />
> Do we need to expand then the property sets for each FO to include the
> inheritable properties (you may already have done so, I'm not sure if
those
> were included)--and do we also need to somehow additionally qualify
*those*
> properties as "valid for the FO but not directly relevant for it"?  (I
> think "yes" for the first question, "no" for the second.)

IIC the initial strategy WRT inherited properties was to add methods to the
FObj's to get these from their parent. I think the problem with this
implementation is that, in the case of very large documents with deeply
nested elements that inherit a property which is specified at the top-level,
you would end up with one getter being dispatched to the parent's getter,
and this in its turn being dispatched to yet another ancestor's getter (or
Makers in case of Property creation)... In this case, however, I think you
can't fully 'push' these onto the descendants, as this would lead to absurd
storage-reqs for quite average-sized documents.

OTOH, the inherited property value (resolved or unresolved) can indeed be
supposed as available at parse time, because a parent is per se processed
*before* any of its children. I just wonder if this has something to do with
Finn's other idea of moving logic to the property side to save on
unnecessary calls to empty methods ?

> 4.)  Finally, I'm too far removed from my C programming days to understand
the
> math here:
>   this.specified = new int[(indices[0] >> 5) + 1];

He's dividing the value by 32 [or 2^5], right?

> (where indices[0] defines the number of properties valid for the FObj)

> also, in putSpecified(int idx, Property value), you code this:

>   specified[i >> 5] |= 1 << (i & 31);

> I'm not clear what this is doing either.  What does putSpecified() do, and
> what's the point of the i & 31 and the Or'ing?

I *definitely* *have* *to* take a closer look at that code!
I *definitely* *have* *to* take a closer look at that code!
I *definitely* *have* *to* take a closer look at that code!
...

That's all I can add for you now, Glen. Sorry :(

Cheers,

Andreas