2010/11/16 Meikel Brandmeyer m...@kotka.de
Salut Laurent,
On 16 Nov., 09:51, Laurent PETIT laurent.pe...@gmail.com wrote:
Agreed with the explanation, but ... 12% of what, exactly ?
6,502692ms / 7,393586ms ~ 0,88 = 12% improvement, no?
But maybe this whole microbenchmarking story is
Hi,
On 17 Nov., 09:44, Laurent PETIT laurent.pe...@gmail.com wrote:
I don't know.
But my thougts were just that if you want to measure the time for a
particular way W of coding things (and a variant Wv), and you test this
with other computations OC,
then
(not=
(/ (time Wv)
(time
2010/11/16 Meikel Brandmeyer m...@kotka.de
Hi,
On 16 Nov., 02:31, Ken Wesson kwess...@gmail.com wrote:
Eh. I'd heard first and rest had replaced next. No?
No. This was a misinformation. To elaborate a bit more on the
differences pointed out by Sean:
next returns nil if there are no
Salut Laurent,
On 16 Nov., 09:51, Laurent PETIT laurent.pe...@gmail.com wrote:
Agreed with the explanation, but ... 12% of what, exactly ?
6,502692ms / 7,393586ms ~ 0,88 = 12% improvement, no?
But maybe this whole microbenchmarking story is paper waste. As I
said: quick'n'dirty.
Will now
On Sun, Nov 14, 2010 at 9:36 PM, Eric Kobrin erl...@gmail.com wrote:
This brought to mind the general case of detecting emptiness. The
current practice of using `seq` to check for non-emptiness wastes
resources.
It depends: in many cases you need to call seq anyway in the non-empty
branch so
Yes, the API *does* suggest using seq to check for emptiness. (empty?
x) is implemented as (not (seq x)). You certainly won't ever get
improved performance by using empty? - at best you break even, most of
the time you lose. For example:
(if (empty? x)
; empty branch
; not-empty branch
Can be
On Nov 15, 2010, at 4:41 PM, Alan wrote:
Yes, the API *does* suggest using seq to check for emptiness. (empty?
x) is implemented as (not (seq x)). You certainly won't ever get
improved performance by using empty? - at best you break even, most of
the time you lose. For example:
The only
On Mon, Nov 15, 2010 at 4:41 PM, Alan a...@malloys.org wrote:
Yes, the API *does* suggest using seq to check for emptiness. (empty?
x) is implemented as (not (seq x)). You certainly won't ever get
improved performance by using empty? - at best you break even, most of
the time you lose. For
Hi,
Am 15.11.2010 um 23:07 schrieb Ken Wesson:
(loop [s some-coll o nil]
(if (empty? s)
o
(let [f (first s)]
(blah blah blah s blah blah blah f blah blah blah)
(recur (rest s) (conj o foobar)
or some similar control flow structure, where s gets first and rest
On Mon, Nov 15, 2010 at 6:49 PM, Meikel Brandmeyer m...@kotka.de wrote:
Changing the above code to the following (which is similarly readable) should
give an immediate speed bump. Rich once stated something around 20%, although
I have not verified the numbers and this was quite a while ago...
On Mon, Nov 15, 2010 at 5:31 PM, Ken Wesson kwess...@gmail.com wrote:
Eh. I'd heard first and rest had replaced next. No?
rest and next do different things:
rest - Returns a possibly empty seq of the items after the first.
Calls seq on its argument.
next - Returns a seq of the items after the
Hi,
On 16 Nov., 02:31, Ken Wesson kwess...@gmail.com wrote:
Eh. I'd heard first and rest had replaced next. No?
No. This was a misinformation. To elaborate a bit more on the
differences pointed out by Sean:
next returns nil if there are no more items in the sequence, which is
nice to use in
In the API it is suggested to use `seq` to check if coll is empty.
I was working on some code recently found that my biggest performance
bottleneck was calling `seq` to check for emptiness. The calls to
`seq` were causing lots of object allocation and taking noticeable CPU
time. I switched to
On Sun, Nov 14, 2010 at 2:16 PM, Eric Kobrin erl...@gmail.com wrote:
In the API it is suggested to use `seq` to check if coll is empty.
I was working on some code recently found that my biggest performance
bottleneck was calling `seq` to check for emptiness. The calls to
`seq` were causing
On Nov 14, 2010, at 2:16 PM, Eric Kobrin wrote:
In the API it is suggested to use `seq` to check if coll is empty.
Your timing results raise some interesting questions, however, the API doesn't
suggest using 'seq' to check if a collection is empty. That's what 'empty?' is
for. The
On Sun, Nov 14, 2010 at 2:42 PM, Ken Wesson kwess...@gmail.com wrote:
user= (let [iterations 1] (time (dotimes [_ iterations]
(= [] (pop [3] (time (dotimes [_ iterations] (seq []
Elapsed time: 29994.93852 msecs
Elapsed time: 2745.21924 msecs
It occurred to me that the JIT
In the particular bit of code I'm working on, I have a collection of
vectors. The last one is always [] and no others are empty. Using
`identical?` instead of `seq` to detect that last vector shaved quite
a bit of time in my loop.
This brought to mind the general case of detecting emptiness. The
On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin erl...@gmail.com wrote:
In the particular bit of code I'm working on, I have a collection of
vectors. The last one is always [] and no others are empty. Using
`identical?` instead of `seq` to detect that last vector shaved quite
a bit of time in my
On Sun, Nov 14, 2010 at 4:33 PM, David Nolen dnolen.li...@gmail.com wrote:
On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin erl...@gmail.com wrote:
In the particular bit of code I'm working on, I have a collection of
vectors. The last one is always [] and no others are empty. Using
`identical?`
On Nov 14, 2010, at 4:04 PM, Ken Wesson wrote:
Interestingly, (= (count v) 0) is relatively fast (900 msec); (seq v)
is slower (2s); (empty? v) is even slower (3s); and (= v []) is
slowest (16s).
Strange. Here are the timings I get for 1e8 iterations:
(zero? (count v)): ~3600 msecs
(seq v):
Some more String-specific timings, modified to avoid inlining
differences between alternatives:
(let [iterations 1e8] (time (dotimes [_ iterations] (= 0 (.length
(.substring x 1) (time (dotimes [_ iterations] (seq (.substring
x 1)
Elapsed time: 3125.125 msecs
Elapsed time: 8198.331 msecs
21 matches
Mail list logo
