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=23924>. 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=23924 Enhanced performance for TagUtils.filter() [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2003-10-20 05:19 ------- Thanks a lot for your consideration and feedback -- this is my first attempt to contribute. As per your message, let me risk being a bother and just present an argument that the benefit is non- trivial, and re-open this. If you still disagree then please re-close it with my apologies. I think the new method is still pretty straightforward and maintainable -- after all I included unit tests to verify any changes. So, I don't necessarily see that as a problem; if these ekes out even a little bit more performance, automatically for any Struts app, then I think it's worth doing (but of course I think that, or I wouldn't have bothered). If anything it is the memory allocation, actually. How about this back-of-the-envelope calculation -- this method is called by bean:write and most HTML form tags (including html:options, mind). In a medium-sized Struts app maybe this translates into 20-50 calls to this method averaged over all pages? (On this Bugzilla bug page, it would be over 200, with all the select inputs.) The allocation per method that can almost always be avoided amounts to 3 objects and 70 bytes in total, at minimum. So the avoidable overhead is maybe 1.4-3.5kbytes per page view? A moderately busy site might get 400 page views per minute? So we're looking at avoiding allocation of maybe 0.5-1.5MB per minute, 24,000-72,000 objects? Sure, less for small apps but more for large enterprise apps. That's not big and basically all can be GC'ed, but not trivial. But from the user's perspective -- would you like your Struts app to be automatically a very little bit faster and use a little less memory? Is it worth us reliably optimizing one method? I'd say so, but leave it to you to decide whether that's so. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
