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

http://issues.apache.org/bugzilla/show_bug.cgi?id=41044





------- Additional Comments From [EMAIL PROTECTED]  2006-12-08 14:05 -------
(In reply to comment #7)

> Andreas, why is your valueCache not also a map on the value?

I thought of that too, but since we're trying to save on resources here I'm a 
bit wary of the extra objects 
a Map generates under-the-hood.
ArrayLists have very low overhead in that respect. Very little more space 
needed on top of the instances 
it stores. Given that the number of distinct values for one attribute is 
expected to remain at a 
reasonable level, I'd even go as far as stating that the list iteration will 
perform roughly the same as a 
map lookup. All we lose by using a List is the extra space needed for the 
Map.Entrys...

> I am not sure that your approach is worth the trouble. 

Indeed, see also Joerg's response on fop-dev.
I was not either, but it would get interesting if such an approach could be 
used on the complex types.

On the other hand, even if you start from a type containing only two String 
instance members, having 
thousands of references to one singular instance of that type is mathematically 
*always* better than 
creating thousands of instances with the two String references being identical. 
The benefit of Richard's approach is that it could rather easily be ported to 
all Property types. My 
approach seems more appropriate for the Attribute type. Looking closer, it 
would get very difficult to 
port it to the properties.

> An EnumProperty and an Attribute object contain only a name and a value, 
> and two more strings in the latter case. It is quite efficient to use that as 
> a key, 
> and creating an object for lookup is not very costly in view of the efficient 
> hash 
> lookup you achieve.
> First doing a lookup on name and then on value may cost more than it saves.

Could be... I really should try to measure it.

> Of course a map in which the key and the value are always identical seems
> strange. I have looked into Set, which guarantees uniqueness of the objects, 
> but
> it does not allow efficient retrieval.

Hence, index-based list-retrieval! 8) 
The uniqueness follows from the implementation, I think... 
If the Maps and Lists are properly synchronized, then there will always be only 
one distinct instance per 
name/value. 
Each get() following the initial put() will return that singular instance.

> At first I was wary about Richard's commenting out of properties. In principle
> every property has an effect on layout and must be looked up. But if we wish 
> to
> release a production version, we cannot waste performance on such a principle.
> Therefore I think a careful commenting out of properties not looked up is 
> useful.

Agreed here. We can always reactivate them later.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to