Ideally, make them debug-level log statements and then enable/disable them at runtime as needed. In practice that means configuring the JDK logger, since that's what SLF4J is using underneath (currently). I always have to fiddle a bit to figure out how to do it.
Or: put in whatever you want for debugging and delete it / comment it out before committing. On Wed, Jan 2, 2013 at 2:43 PM, Dan Filimon <[email protected]> wrote: > What I'm looking for, is a way of collecting runtime stats without > having 2 versions of the code (one that prints it out and one that > doesn't). > How could I do this without logging? > > On Wed, Jan 2, 2013 at 4:40 PM, Ted Dunning <[email protected]> wrote: >> The normal answer is that we use slf4j. If you log at debug or info level, >> then your conditionals shouldn't be necessary. >> >> Returning the log as a stream is pretty unusual, but some high performance >> systems can't handle the overhead of even something like slf4j. Typically, >> this is because these systems need to make the decision about logging level >> somewhat after the fact ... i.e. they need to log at a substantial level, >> but only store the results if something goes wrong. >> >> I don't think that streaming k-means is in this category. >> >> On Wed, Jan 2, 2013 at 4:05 AM, Dan Filimon >> <[email protected]>wrote: >> >>> I can add a Logger as a member variable and log the progress there, or >>> can just to printfs (which seems really dirty). >>> >>> What's the best way of doing this? I'd prefer having the output, at >>> least when evaluating the quality of the code, but on the other hand >>> it'd be nice to disable logging when running in production. >>> >>> I'm thinking of adding Logger progressLogger and a boolean >>> enableLogging variables to the algorithm classes to control this. >>> >>> But then, it'd also be nice to return the log as a stream when the >>> algorithm is done. So, there'd be a getLog() method. >>>
