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.
