Indeed. It's generally regarded as an anti-pattern. evebill8: See below for a couple of links talking about it if your co-workers grumble about it (and for anyone else who comes along asking these questions, I guess).
http://c2.com/cgi/wiki$?PrematureOptimization http://prematureoptimization.org/blog/archives/26 http://www.flounder.com/optimization.htm Once you've read the above 3, read this one: http://www.acm.org/ubiquity/views/v7i24_fallacy.html Which provides a nice sanity check. - Andrew Thorburn On Fri, Feb 5, 2010 at 8:48 PM, Adrian Crum <[email protected]> wrote: > This is good advice. I have seen innumerable emails that follow this same > format: "I want to change x code because it could be a performance problem." > If you were having performance problems, then any number of code profilers > will tell you where the bottleneck is. Just looking at a code fragment and > assuming it will be a performance bottleneck is not wise. > > -Adrian > > --- On Thu, 2/4/10, Martin Cooper <[email protected]> wrote: > >> From: Martin Cooper <[email protected]> >> Subject: Re: Is DiskFileItemFactory Thread Safe? >> To: "Commons Users List" <[email protected]> >> Date: Thursday, February 4, 2010, 9:21 PM >> Unless you're using a truly antique >> version of Java, the cost of >> repeatedly instantiating DiskFileItemFactory is entirely >> negligible. >> The constructor does next to nothing, and the JVM already >> optimizes >> repeated class instantiations almost out of existence. If >> you are >> seeing performance issues with heavy load on your servlet, >> this is >> _not_ what you need to be looking at, believe me. >> >> To answer your question, though, the class is here: >> >> http://svn.apache.org/repos/asf/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java >> >> from which you can see that there's not a lot going on in >> there. >> >> -- >> Martin Cooper >> >> >> On Thu, Feb 4, 2010 at 10:25 AM, evebill8 <[email protected]> >> wrote: >> > >> > I have a servlet that will handle few hundread >> thousand requests per day. I >> > am using the commons FileUpload to loop thru the >> fields and file items. >> > Here is the code >> > >> > >> > public void doPost(HttpServletRequest req, >> HttpServletResponse res) >> > throws ServletException, IOException >> { >> > >> > try { >> > DiskFileItemFactory factory = new >> DiskFileItemFactory(); >> > >> > ServletFileUpload upload = new >> ServletFileUpload(factory); >> > List<FileItem> items = >> upload.parseRequest(req); >> > >> > for (FileItem item : items) { >> > .... >> > } >> > } >> > catch (Exception e) { >> > ... >> > } >> > } >> > >> > Since the servlet is being called so many times, can I >> make the >> > DiskFileItemFactory global static so it won't create >> the factory object so >> > many times? In sum, is DiskFileItemFactory class >> thread safe? >> > >> > >> > DiskFileItemFactory factory = new >> DiskFileItemFactory(); >> > >> > public void doPost(HttpServletRequest req, >> HttpServletResponse res) >> > throws ServletException, IOException >> { >> > >> > try { >> > >> > ServletFileUpload upload = new >> ServletFileUpload(factory); >> > List<FileItem> items = >> upload.parseRequest(req); >> > >> > for (FileItem item : items) { >> > .... >> > } >> > } >> > catch (Exception e) { >> > ... >> > } >> > } >> > >> > Thanks! >> > >> > -- >> > View this message in context: >> > http://n4.nabble.com/Is-DiskFileItemFactory-Thread-Safe-tp1469216p1469216.html >> > Sent from the Commons - User mailing list archive at >> Nabble.com. >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
