Hi,
On 17 Nov., 09:44, Laurent PETIT 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 W))
>
2010/11/16 Meikel Brandmeyer
> Salut Laurent,
>
> On 16 Nov., 09:51, Laurent PETIT 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: qui
Salut Laurent,
On 16 Nov., 09:51, Laurent PETIT 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 drop out of perfomance di
2010/11/16 Meikel Brandmeyer
> Hi,
>
> On 16 Nov., 02:31, Ken Wesson 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 sequen
Hi,
On 16 Nov., 02:31, Ken Wesson 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 if and when stateme
On Mon, Nov 15, 2010 at 5:31 PM, Ken Wesson 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 first. Calls seq o
On Mon, Nov 15, 2010 at 6:49 PM, Meikel Brandmeyer 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...
>
> (loop
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 re
On Mon, 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:
>
> (if
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 on
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 Sun, Nov 14, 2010 at 9:36 PM, Eric Kobrin 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 seq+if-let is
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
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)
On Sun, Nov 14, 2010 at 4:33 PM, David Nolen wrote:
> On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin 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
On Sun, Nov 14, 2010 at 3:36 PM, Eric Kobrin 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 loop.
The
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
c
On Sun, Nov 14, 2010 at 2:42 PM, Ken Wesson 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 might not be h
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 documentat
On Sun, 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.
>
> 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
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 usin
21 matches
Mail list logo
