Excellent, thanks for the information.

I just did a benchmark of zipmap over keys and vals vs. into {} over a map, 
and despite my intuition, they are actually nearly identical in 
performance. So if zipmap were using transients zipmap with keys and vals 
would actually be the better performing option here.

user> (def testmap (zipmap (range 1000) (range 2000 3000)))
user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap))))
Evaluation count : 150900 in 60 samples of 2515 calls.
             Execution time mean : 401.458681 µs
    Execution time std-deviation : 4.912358 µs
   Execution time lower quantile : 393.882254 µs ( 2.5%)
   Execution time upper quantile : 409.534676 µs (97.5%)
                   Overhead used : 2.203076 ns

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil
user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
Evaluation count : 150060 in 60 samples of 2501 calls.
             Execution time mean : 400.684810 µs
    Execution time std-deviation : 3.489015 µs
   Execution time lower quantile : 395.127605 µs ( 2.5%)
   Execution time upper quantile : 407.132405 µs (97.5%)
                   Overhead used : 2.203076 ns
nil


On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose Bonnaire-Sergeant 
wrote:
>
> It also might help to notice KeySeq defines first/next, but never 
> explicitly walks the seq.
>
> That's left to the user of the KeySeq.
>
> Thanks,
> Ambrose
>
>
> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk 
> <michal....@gmail.com<javascript:>
> > wrote:
>
>> On 2 February 2014 05:14, Justin Smith <noise...@gmail.com 
>> <javascript:>>wrote:
>>
>>> Pardon my ignorance but if this is producing a lazy result, how is it 
>>> doing so?
>>>
>>> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>>>
>>
>> APersistentMap's KeySeq.create and ValSeq.create are pretty much 
>> equivalent to (map key entry-seq) and (map val entry-seq). The logic 
>> producing entry-seq lives in the individual map types and is indeed lazy.
>>
>> Cheers,
>> Michał
>>  
>>
>>>
>>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
>>>> zipmap could also potentially use transients (which would be a nice 
>>>> addition).
>>>>
>>>> keys/vals are also lazy, so I would be surprised if there was any 
>>>> performance
>>>> difference with walking the seq "twice".
>>>>
>>>> Thanks,
>>>> Ambrose
>>>>
>>>>
>>>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith <noise...@gmail.com>wrote:
>>>>
>>>>> Realistically, how many situations are there where running keys and 
>>>>> vals independently is preferable to running seq once and using the two 
>>>>> element vectors that returns?
>>>>>
>>>>> Usually this way one can avoid walking the whole thing twice.
>>>>>
>>>>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative 
>>>>> of the idiom I usually use. As a bonus, into uses transients, which can 
>>>>> create the resulting structure in fewer cycles / less time.
>>>>>
>>>>>
>>>>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>>>>
>>>>>> Looks like Rich just chimed in with:
>>>>>>
>>>>>> "keys order == vals order == seq order "
>>>>>>
>>>>>>   Matching Socks
>>>>>>  January 31, 2014 7:31 PM
>>>>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
>>>>>> consistency not mentioned in docstring" was declined, with the comment 
>>>>>> "The 
>>>>>> absence of this property in the docs is correct. You should not rely on 
>>>>>> this."
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Clojure" group.
>>>>>> To post to this group, send email to clo...@googlegroups.com
>>>>>>
>>>>>> Note that posts from new members are moderated - please be patient 
>>>>>> with your first post.
>>>>>> To unsubscribe from this group, send email to
>>>>>> clojure+u...@googlegroups.com
>>>>>>
>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/group/clojure?hl=en
>>>>>> --- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "Clojure" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to clojure+u...@googlegroups.com.
>>>>>>
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>  
>>>>>>
>>>>>> -- 
>>>>>> Sam Ritchie (@sritchie)
>>>>>>  Paddleguru Co-Founder
>>>>>> 703.863.8561
>>>>>> www.paddleguru.com
>>>>>> Twitter <http://twitter.com/paddleguru> // 
>>>>>> Facebook<http://facebook.com/paddleguru>
>>>>>>  
>>>>>  -- 
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To post to this group, send email to clo...@googlegroups.com
>>>>> Note that posts from new members are moderated - please be patient 
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> clojure+u...@googlegroups.com
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/clojure?hl=en
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Clojure" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to clojure+u...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com <javascript:>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to