DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11028>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11028 [PATCH] HSSFColor to use instanciations rather than seperate classes ------- Additional Comments From [EMAIL PROTECTED] 2002-07-24 07:16 ------- But isnt there only one instance of each color object being created? they were defined as public static final right? I think that you mean that the color BLACK (for instance) is always created but it may never be used, whereas in the existing approach the BLACK instance is only created at the time that it is required. Whilst I see your point, I dont think that the overhead of a few default pallette colours is that bad compared with the memory used when reading in the XLS files. Maybe the overhead (both memory and speed) of the class loader being invoked many times in loading the color classes will negate any perceived benefits, but I really dont know. I know that you should try to reduce the number of objects created, however I dont know that if the approach that exists is any better in the long run (but id like to be corrected ;-) ) Like many things there is a trade off between code readibility and maintenance, speed and memory usage. Obviously since I made the patch I believe that this approach, whilst it may sacrifice some memory, is better in the long run. What do you think? Is the patch worth the perceived increase in memory? Jason -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
