Benchmark: timing 1000000 iterations of exists, true… exists: 7 wallclock secs ( 6.52 usr + 0.02 sys = 6.54 CPU) true: 7 wallclock secs ( 6.28 usr + 0.00 sys = 6.28 CPU) There is no (significant) difference. Use the Benchmarkmodule to compare the relative speeds of different code strategies. What else can we learn from this Perl of Wisdom? Well, you may be wondering why there was no complaint in the first Benchmark example about the hash %h not being declared. We can infer from section 3.6.1 (pointing out that usestrict is lexically scoped) that Benchmark evaluates each chunk of code in a lexical scope that is separate from the one enclosing it. So if the code you’re testing is long enough to be worth strictchecking, put use strict at the beginning of each chunk. This scoping effect also means that any lexical variables you declare in the main program won’t be visible inside the benchmark code chunks. We should point out that there is rarely any point to benchmarking code that isn’t going to be run many, many times by your program. So if it’s just code that’s going to be run once, don’t bother benchmarking it unless it either (a) takes a really, really long time or (b) needs to run very, very quickly (e.g., has to respond to a user in real time). Benchmarking needs careful thought and can be an art. Benchmark the wrong thing, and the conclusion you draw can easily be the opposite of the right one. Suppose you’re benchmarking code that uses a constant function inside a loop. If you put the definition in the code chunk, it’ll get executed once for each iteration, whereas in your program it will get executed only once. The difference between the two approaches is seen in this benchmark, which shows how the result is changed by putting the constant definition in the loop: use constant OUTSTR => ‘The cat sat on the mat’; timethese(10000000, { inconst => q(use constant INSTR => ‘The cat sat on the mat’; INSTR =~ /cat/), outconst => q(OUTSTR =~ /cat/), }); inconst: 31 wallclock secs (31.27 usr + 0.00 sys = 31.27 CPU) outconst: 29 wallclock secs (28.78 usr + 0.00 sys = 28.78 CPU) Notice how we used the q() operator instead of ‘…’ to make a visual block out of the code chunks.
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services