On Mon Apr 9 18:54 2012, Tassilo Horn wrote: > To check that, I've created the simple benchmark below that runs the > current and enhanced implementation 10 million times with a evenly > distributed set of numbers, Booleans "created properly" with valueOf(), > Booleans created with the constructor, Strings, and nulls. > > To my amazement, the variant that explicitly checks for Boolean wrapper > objects is not at all slower. On my machine with IcedTea7-2.1, the 10 > million checks with either the current null/false-check or the > null/false/Boolean-check take about 155 milliseconds. > > So at least from a performance standpoint, there doesn't seem to be a > reason not to do it. It's just a semantic question: should > (Boolean. false) bo a truthy thing? Right now, it is and the docs state > that. But is that good, especially since this topic pops up every few > months on the list? And equally important: is there existing code that > relies on (Boolean. false) being truthy?
Unfortunately, your methodology is flawed. The overhead of iterating through a list and converting the ints into objects is obscuring the perfomance difference between the two. Running a modified version of the code (attached) using an instrumenting profiler shows that the version that checks for the Boolean instance is about 6% slower than the version that does not. In any case, these are somewhat meaningless micro-benchmarks. Ultimately, whether or not Clojure’s if should handle (Boolean. false) is more of a design/philosophical question. Sincerely, Daniel
signature.asc
Description: Digital signature
