From: Justin D. <jde...@op...> - 2010-02-25 20:55:58
|
Very good reasons, thank you. I am now a converter and will guard all log statements :) -Justin On 2/25/10 10:28 AM, Andrea Aime wrote: > Simone Giannecchini wrote: >> Well, I can give you the bkg for this rule. >> >> For one of our client we have been using a custom logging lib that was >> loggingo onto a JMS queue. >> We were not using guarded logging and we were having some large >> performance differences depending on the conditions of the system. >> We investigated and we noticed that there was code inside the logging >> lib that was building the JMS machinery every time before checking the >> level. >> So better guard the code than change the lib. >> >> Another exafrom a couple of years ago. In another custom library (that >> was C++), I noticed that logging seemed to be heavy. >> I investigated and again, the library was building the final message >> prior to checking the level which meant getting the local time and >> formatting it and that can be expensive. >> Again better guard the code than change the lib. >> >> Another example if when in your message you get the stacktrace and >> then you spit it out. This can be really heavy so better guarding the >> code rather than gathering the stack trace and throwing it away. >> >> In the end, I usually recommed/require to use it. > > I don't really like to see the code riddled with ifs everywhere, > but I can also add another good reason to add guards: log4j logging > calls are synchronized, they kill scalability if they're put in tight > loops. > > However, for the JMS case remember we're using a indirection level > to get to the real logging, that can be used to avoid the actual > logging calls so there is not really a need to guard INFO and above, > just the FINE ones in tight loops should be enough. > > Cheers > Andrea -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |