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.