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-07 12:33 -------

Richard,

(In reply to comment #1)
> Created an attachment (id=19176)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19176&action=view) 
[edit]
> Replace EnumProperty and EnumNumber constructors with getInstance()

Looking again at your patch, one more remark: 
The only thing that doesn't completely sit right with me, is the lookup based 
on an instance of the class 
in question... This seems to me to defeat the purpose of reducing the 
instantiation rate. True, the 
instance's scope remains limited to the getInstance() method, but they're 
created (and have to be GC'ed) 
anyway :/
[Compare it to String internalization: I doubt the JVM creates a String 
instance first and throws it away 
afterwards if an internalized String for that text already exists. I'd think 
the extra instance is never even 
created...?]

See my proposed change in Marker.java: the MarkerAttribute constructor is 
called only when no 
corresponding instance exists in the map yet. I'm still chewing on how to 
generalize such an approach 
in the properties package. 
In the meantime, also did something similar for fo.expr.NumericProperty... 
again nothing broke, but I 
still have to dig up a testcase, to see how precisely this impacts the resource 
consumption before 
committing such stuff.

Example of the expected results of the change in Marker.java:
suppose 200 Markers, one-element subtree with attribute-set of 10 attributes

BEFORE: 
2000 separate MarkerAttribute instances w/ 4 String references each, good for 
8000 Strings in toto.

Case 1
-> recurring identical attribute-set
AFTER: 1 Map with 10 entries, 10 Strings plus 10 Lists consisting of one 
MarkerAttribute instance each, 
makes a total of only 10 instances (40 Strings) and 2000 references to one of 
those 10 instances.

Case 2
-> distinct attribute-sets (recurring names, different values)
NEW: 1 Map with 10 entries, 10 Strings plus 10 Lists consisting of 200 
MarkerAttribute instances each... 
Slight drawback because of the added Map + List instances, and the overhead of 
the lookup.

The rest lies somewhere in between.
The general use-cases would incline towards Case 1 more than Case 2 (or even a 
case where there are 
200 distinct attribute-sets that have absolutely no common attributes). The 
more distinct names, the 
larger the Map, but this is limited to PROPERTY_COUNT keys. The Lists can be 
expected to remain 
reasonably sized (practical limitations on the number of distinct possible 
values)

If the synchronization works out as expected, a generalized approach for all 
Property subtypes could 
vastly reduce memory usage in multi-thread context (the above figures 
multiplied by a factor of 15, or 
more), especially if all the different threads use the same set of templates, 
generating heaps of identical 
attributes.

-- 
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