Re: Functions using locks are slowed even when locks are never taken
Verified that I receive the same result patterns as you on my machine. One other possibility outside of what you have already mentioned would be something JIT-related. Perhaps there is an optimization that can be performed if the locking sections of the code are in another function but otherwise no, but I'm not sure how that dovetails with Clojure' fn compilation. On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote: Since 1.6 alpha is out, I reran the tests with that -- basically the same results. On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns Execution time sample std-deviation : 0.718382 ns Execution time std-deviation : 0.729431 ns Execution time lower quantile : 24.837925 ns ( 2.5%) Execution time upper quantile : 27.595781 ns (97.5%) Overhead used : 1.634996 ns Found 4 outliers in 60 samples (6.6667 %) low-severe 2 (3. %) low-mild 2 (3. %) Variance from outliers : 15.7591 % Variance is moderately inflated by outliers done benching -- -- 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
Re: Any interest in Compojure/Ring screencasts?
Count me in Rudi On 30 Oct 2013, at 1:36 PM, Yuan lend...@gmail.com wrote: Count me in too.. _ Best regards - Yuan blog github On Wed, Oct 30, 2013 at 7:19 AM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Count me in, Luc P. I'm considering putting together a screencast, or a series of screencasts, based on my Functional Web Architecturehttp://skillsmatter.com/podcast/home/functional-web talk. The base presentation would be improved, and I'd probably wind up going into more detail on certain topics. I'll probably charge a small fee (perhaps $10 or so) to cover costs. Would there be any interest in this? - James -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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. -- -- 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. -- -- 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.
Re: Potential improvement to select-keys ?
Our emails crossed paths, timing-wise, but my response to this is that not all types of maps can safely be dumped into a regular map, so there's not much reason to think that the standard behavior would be to build up from scratch using a regular map. Example? I can't think of one. Any key/value pair you retrieve from any map can be put in a regular map, right? Note that the current behavior is to do exactly this. -- -- 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.
Re: Potential improvement to select-keys ?
One other point: Sometimes people use sorted maps and array maps specifically for scenarios in which the keys are not hashable and therefore hash maps would not apply. Dumping the contents into a regular map in such cases doesn't make much sense. Everything is hashable, not sure what a non-hashable key means. Array maps use the hash of the key to determine the array bucket. If you get the hash code of a sorted map, it will get the hash of all keys and values. -- -- 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.
Re: Potential improvement to select-keys ?
I attached another patch to the ticket. It builds up the answer from the
empty map {} if the argument is a record (as the current select-keys does),
but from (empty map) if it is not a record, so it will preserve sortedness
of the argument. Not sure if there are any other cases that are a problem,
or if it does what everyone would expect, but it should be closer.
http://dev.clojure.org/jira/browse/CLJ-1287
Andy
On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller a...@puredanger.com wrote:
One other point:
Sometimes people use sorted maps and array maps specifically for
scenarios in which the keys are not hashable and therefore hash maps would
not apply. Dumping the contents into a regular map in such cases doesn't
make much sense.
Everything is hashable, not sure what a non-hashable key means. Array maps
use the hash of the key to determine the array bucket. If you get the hash
code of a sorted map, it will get the hash of all keys and values.
--
--
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.
--
--
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.
Re: Potential improvement to select-keys ?
On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller a...@puredanger.com wrote: One other point: Sometimes people use sorted maps and array maps specifically for scenarios in which the keys are not hashable and therefore hash maps would not apply. Dumping the contents into a regular map in such cases doesn't make much sense. Everything is hashable, not sure what a non-hashable key means. Array maps use the hash of the key to determine the array bucket. If you get the hash code of a sorted map, it will get the hash of all keys and values. Infinite sequences are not hashable. They can be sorted lexicographically, provided you know in advance you're not working with two equal sequences. I believe that array maps just store items in the order you put them in, never computing the hash. Not sure that using infinite sequences as keys is a common use case, but when I wrote that, I was thinking that might be representative of a larger set of examples where it is impossible or impractical to compute the hashes of your keys. -- -- 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.
Re: Potential improvement to select-keys ?
I seem to be a relatively lone voice thinking it makes sense to preserve
the type of the map, and honestly, I'm not going to lose any sleep if this
patch is never actually implemented, but here's my two cents on the
optimal design for records.
Earlier in the thread, I mentioned two mental models about how select-keys
works. Even though the actual implementation involves starting from an
empty map and building back up, I think the behavior of select-keys should
mimic the mental model of discarding irrelevant keys.
The two mental models predict somewhat differently what would happen when
working with records. Records can hold additional keys. So imagine
someone dumps a whole lot of additional keys, and then wants to recover
the original, true record, by calling select-keys with the original keys in
the record. I think this is a use case worth supporting. This corresponds
to the mental model of discarding unwanted keys.
To implement this for records:
If any of the original record keys do not appear in the selected keys,
then, as with dissoc, we must revert back to a map as there is no valid way
to represent this as a record.
Otherwise, maintain the record type -- the core record contents are
preserved, and essentially you only need to call select-keys only on the
extended map of extra keys stored in the record.
On Sat, Nov 2, 2013 at 8:49 AM, Andy Fingerhut andy.finger...@gmail.comwrote:
I attached another patch to the ticket. It builds up the answer from the
empty map {} if the argument is a record (as the current select-keys does),
but from (empty map) if it is not a record, so it will preserve sortedness
of the argument. Not sure if there are any other cases that are a problem,
or if it does what everyone would expect, but it should be closer.
http://dev.clojure.org/jira/browse/CLJ-1287
Andy
On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller a...@puredanger.com wrote:
One other point:
Sometimes people use sorted maps and array maps specifically for
scenarios in which the keys are not hashable and therefore hash maps would
not apply. Dumping the contents into a regular map in such cases doesn't
make much sense.
Everything is hashable, not sure what a non-hashable key means. Array
maps use the hash of the key to determine the array bucket. If you get the
hash code of a sorted map, it will get the hash of all keys and values.
--
--
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.
--
--
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.
--
--
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.
Re: Request for help optimising a Clojure program
A few minutes ago I finished copying, pasting, and doing a little reformatting on Mark Engelberg's document on the subject. http://dev.clojure.org/display/design/Better+hashing Andy On Fri, Nov 1, 2013 at 11:28 AM, Alex Miller a...@puredanger.com wrote: Has anyone created a design page on dev.clojure for this yet? On Thursday, October 31, 2013 9:19:23 AM UTC-5, Andy Fingerhut wrote: Just a follow up after a fair amount of thinking and experimentation has been done on this problem. Mark Engelberg has a very nice document describing the existing hash functions used by Clojure, examples with why they can cause collisions so often, and suggestions for changes to them to have fewer collisions in these cases. https://docs.google.com/document/d/10olJzjNHXn1Si1LsSvjNqF_ X1O7OTPZLuv3Uo_duY5o/edit I have made modifications to a fork of the Clojure code base with his suggested hash modifications here, for experimentation purposes: https://github.com/jafingerhut/clojure I also have some modifications to Paul's N-queens Clojure program to print out additional statistics and try out different hash functions here: https://github.com/ jafingerhut/chess-clojure Running Paul's N-queens problem with a 6x6 board without any changes to Clojure takes about 7 mins on one of my computers. With those changes to the hash functions it finishes in about 12 sec. I haven't let a 6x9 board run to completion without those hash changes, but it takes a long time :-) With those changes to the hash functions it finishes in about 11 minutes. The reason for the currently slow behavior is a combination of the current hash functions and the implementation of the PersistentHashSet data structure used to implement sets. A PersistentHashSet is, very roughly, a 32-way branching tree with the hash function of the elements used to decide which branch to take. When you hit a leaf in the tree, all elements with the same hash function value are put into an array that is scanned linearly whenever you want to check whether a value is already in the set. So the more hash collisions, the more it is like using an array to store and look up set elements in O(n) time. With the 6x9 board, there are 20,136,752 solutions. The way those solutions are represented in the program as sets of vectors, those 20 million values only have 17,936 different hash values. Thus the average length of those arrays of values in the tree leaves is 1,122 values. The longest of those arrays has 81,610 values in it, all with the same hash function. With Mark's proposed hash function changes, those 20,136,752 values hash to 20,089,488 different ints, for an average array length of 1 value, and a longest array length of 3 values. Big speedup. There is nothing unique about Mark's particular hash functions that achieves this. Other hash modifications can give similar improvements. The Clojure dev team is considering which changes would be good ones to make, in hopes of changing them once and not having to do it again. Andy On Tue, Oct 22, 2013 at 9:28 AM, Paul Butcher pa...@paulbutcher.comwrote: I've been playing around with a generalised version of the N-Queens problem that handles other chess pieces. I have a Scala implementation that uses an eager depth-first search. Given enough RAM (around 12G - it's very memory hungry!) it can solve a 6x9 board with 6 pieces in around 2.5 minutes on my MacBook Pro. I then created a Clojure version of the same algorithm with the intention of (eventually) using laziness to avoid the memory issue. However, the performance of the Clojure version is several orders of magnitude worse than the Scala version (I've left it running overnight on the problem that the Scala version solves in 2.5 minutes and it still hasn't completed). I'm struggling to see why the performance of the Clojure version is so much worse than the Scala. Profiling in YourKit suggests that it's spending 99% of its time in PersistentHashSet.cons, but I'm at a loss to explain why. I would be grateful for any insight. The code for the two different versions is on GitHub: https://github.com/paulbutcher/chess-scala https://github.com/paulbutcher/chess-clojure Notes: - I know that an exhaustive depth-first search isn't a great way to tackle this problem. But I'd like to understand why I see such a dramatic difference between the performance of the Scala and Clojure versions. - I believe that I've implemented the same algorithm in both Scala and Clojure - certainly they both generate the same results for small problems (there are 3x3 and 4x4 problems commented out in the source). But clearly I can't rule out the possibility that I've made a mistake in the Clojure implementation. If anyone can spot my stupid mistake, I'd greatly appreciate it. Thanks in advance for any insight that anyone can offer. -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who
assoc / dissoc consistency, maps and vectors
I realize `dissoc` isn't implemented to work on vectors for technical reasons (such as explained on 1/13/11 here https://groups.google.com/forum/#!msg/clojure/Lx9ysZ4ndfw/E52rVTvclMoJ ). It'd be nice if it did as I still get surprised by this on occasion, it feels like an inconsistency when using Clojure such that I'd imagine it's a general point of frustration for others as well. (assoc [1 2 3] 1 'a) ;= [1 a 3] (dissoc ['a 'b 'c] 1) ;= ClassCastException clojure.lang.PersistentVector cannot be cast to clojure.lang.IPersistentMap clojure.lang.RT.dissoc (RT.java:759) (assoc-in [['a 'b] ['c 'd]] [1 1] 'x) ;= [[a b] [c x]] (clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1]) ;= ClassCastException clojure.lang.PersistentVector cannot be cast to clojure.lang.IPersistentMap clojure.lang.RT.dissoc (RT.java:759) -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
What would you expect the return value of (dissoc ['a 'b 'c] 1) to be? On Sat, Nov 2, 2013 at 11:03 AM, vrak...@gmail.com wrote: I realize `dissoc` isn't implemented to work on vectors for technical reasons (such as explained on 1/13/11 here https://groups.google.com/forum/#!msg/clojure/Lx9ysZ4ndfw/E52rVTvclMoJ ). It'd be nice if it did as I still get surprised by this on occasion, it feels like an inconsistency when using Clojure such that I'd imagine it's a general point of frustration for others as well. (assoc [1 2 3] 1 'a) ;= [1 a 3] (dissoc ['a 'b 'c] 1) ;= ClassCastException clojure.lang.PersistentVector cannot be cast to clojure.lang.IPersistentMap clojure.lang.RT.dissoc (RT.java:759) (assoc-in [['a 'b] ['c 'd]] [1 1] 'x) ;= [[a b] [c x]] (clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1]) ;= ClassCastException clojure.lang.PersistentVector cannot be cast to clojure.lang.IPersistentMap clojure.lang.RT.dissoc (RT.java:759) -- -- 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. -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
On Saturday, November 2, 2013 1:16:42 PM UTC-5, Andy Fingerhut wrote: What would you expect the return value of (dissoc ['a 'b 'c] 1) to be? Hi Andy, Thanks for your interest! This is the ideal behavior I would expect from dissoc, for consistency with assoc: (assoc ['a 'b 'c] 1 'x) ;= ['a 'x 'c] (dissoc ['a 'b 'c] 1) ;= ['a 'c] (assoc-in [['a 'b] ['c 'd]] [1 1] 'x) ;= [[a b] [c x]] (clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1]) ;= [[a b] [c]] -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
On Sat, Nov 2, 2013 at 11:51 AM, vrak...@gmail.com wrote: (dissoc ['a 'b 'c] 1) ;= ['a 'c] So then (get (dissoc some-vector i) i) would be equivalent to (get some-vector (inc i))? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
On Saturday, November 2, 2013 2:20:40 PM UTC-5, Ben wrote:
So then (get (dissoc some-vector i) i) would be equivalent to (get
some-vector (inc i))?
(def some-vector ['a 'b 'c 'd 'e])
(assoc some-vector 0 'x)
;= [x b c d e]
(dissoc some-vector 0) ;; proposed
;= [b c d e]
(assoc some-vector 1 'x)
;= [a x c d e]
(dissoc some-vector 1) ;; proposed
;= [a c d e]
(assoc some-vector 2 'x)
;= [a b x d e]
(dissoc some-vector 3) ;; proposed
;= [a b d e]
(def some-map {0 'a 1 'b 2 'c 3 'd 4 'e})
(assoc some-map 0 'x)
;= {0 x, 1 b, 2 c, 3 d, 4 e}
(dissoc some-map 0)
;= {1 b, 2 c, 3 d, 4 e}
(assoc some-map 1 'x)
;= {0 a, 1 x, 2 c, 3 d, 4 e}
(dissoc some-map 1)
;= {0 a, 2 c, 3 d, 4 e}
(assoc some-map 2 'x)
;= {0 a, 1 b, 2 x, 3 d, 4 e}
(dissoc some-map 2)
;= {0 a, 1 b, 3 d, 4 e}
--
--
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.
Re: assoc / dissoc consistency, maps and vectors
On Saturday, November 2, 2013 2:38:57 PM UTC-5, vra...@gmail.com wrote: (assoc some-vector 2 'x) ;= [a b x d e] (dissoc some-vector 3) ;; proposed ;= [a b d e] Typo: (assoc some-vector 2 'x) ;= [a b x d e] (dissoc some-vector 2) ;; proposed ;= [a b d e] -- -- 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.
[Video] Introduction to Light Table
Hi everyone, I've recorded an introduction to Light Tablehttp://www.youtube.com/watch?v=1f13TTu_X9k screencast. During which I explain why I'm excited about LT and its future, give a quick introduction to getting started with Clojure in LT, and finally cover some basics around customising keymaps and behaviours. I hope that someone here finds it useful. Cheers, James -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
Problem is, when your proposed dissoc removes value from a vector, it shifts all larger keys. So dissoc would not only remove value at index position, but also change keys for pther values. And this is not what dissoc should do user= (map-indexed vector [:a :b :c :d]) ([0 :a] [1 :b] [2 :c] [3 :d]) user= (dissoc [:a :b :c :d] 1) ;; your proposal [:a :c :d] user= (map-indexed vector [:a :c :d]) ([0 :a] [1 :c] [2 :d]) JW On Saturday, November 2, 2013 8:40:37 PM UTC+1, vra...@gmail.com wrote: On Saturday, November 2, 2013 2:38:57 PM UTC-5, vra...@gmail.com wrote: (assoc some-vector 2 'x) ;= [a b x d e] (dissoc some-vector 3) ;; proposed ;= [a b d e] Typo: (assoc some-vector 2 'x) ;= [a b x d e] (dissoc some-vector 2) ;; proposed ;= [a b d e] -- -- 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.
Re: request for feedback
Hi Julien, Thank you so much for the feedback! I added these ideas to the readme. I was also thinking about email notifications. I have few Clojure libraries and it will be useful for me. I would say that it can be useful also for application developers. If you have big Clojure app I guess it's useful to get notification that some library was updated. Thanks for the link to sonatype. I didn't know about license analysis! Anton On Thursday, October 31, 2013 6:25:36 PM UTC-4, Julien wrote: Very nice! Definitively something I find useful. I guess most are already part of your todo list but here are some features I think might be interesting for library writers: * receive some notification when new versions are available * update some dedicated branch with new versions so they can be tested by continuous integration system for early feedback Beyond that here are suggestions of somewhat orthogonal ideas: * allow to add metadata to libraries (like known bugs, security issues) = you could then qualify the urgency to update some dependency * resolve license conflicts (say your license is incompatible with the license of one of the dependencies) (sonatype has some product doing that: http://www.sonatype.com/application-health-check) Maybe some sort of extension mechanism could be helpful? Julien Le mercredi 30 octobre 2013 21:09:02 UTC-3, Anton Podviaznikov a écrit : Hey everyone, I'm working on project called jarkeeper ( https://github.com/hashobject/jarkeeper.com). It's a simple tool that may be helpful in few cases: 1. Can help you understand if some Clojure library uses latest dependencies (e.x. http://www.jarkeeper.com/korma/Korma) 2. Provides status of dependencies in your own Clojure projects. I'm curious if anyone founds this useful (because I'm thinking on adding more functionality). Appreciate any feedback. P.S. Most of the work is done inside https://github.com/xsc/ancient-clj library. Also there is similar project. Anton Podviaznikov -- -- 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.
Re: assoc / dissoc consistency, maps and vectors
On Saturday, November 2, 2013 4:56:13 PM UTC-5, Jozef Wagner wrote:
Problem is, when your proposed dissoc removes value from a vector, it
shifts all larger keys. So dissoc would not only remove value at index
position, but also change keys for pther values. And this is not what
dissoc should do
You're right. I'm not sure why this is suddenly clear without essentially
any new information. :) I think I had the wrong conceptual impression of
what assoc and dissoc should be, putting the emphasis on the generality of
the collection types instead its specificity to the indicies.
For my notion of assoc/dissoc to hold parity, it would have to work like
this which seems undesirable:
(def some-vector ['a 'b 'c 'd 'e])
(def some-map {0 'a 1 'b 2 'c 3 'd 4 'e})
(assoc some-vector 2 'x)
;= [a b x d e]
(dissoc some-vector 2) ;; theoretical
;= [a b d e] ;; theoretical
(assoc some-map 2 'x)
;= {0 a, 1 b, 2 x, 3 d, 4 e}
(dissoc some-map 2)
;= {0 a, 1 b, 2 d, 3 e} ;; not good
--
--
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.
What's the -dup in print-dup?
This isn't a very deep question, but I wonder every time I come across it: to what does -dup in `print-dup` and `*print-dup*` refer? Thanks - John -- -- 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.
[ANN] Narrator: expressive, composable stream analysis
https://github.com/ztellman/narrator This is a reimplementation of an approach I've discussed in several talks [1] [2], with an eye towards performance, memory efficiency, and flexibility w.r.t. how the event stream is represented. The readme does a good job of explaining how it works, but there have been a number of new event processing libraries recently (core.async, EEP, etc.), so I'll spend some time here describing how this differs. First, this library is focused on aggregations over event streams, not arbitrary transformations. It is designed such that these aggregations can be automatically parallelized, and use non-thread-safe data structures (such as those in the excellent stream-lib [3]) without having to worry about coordination. As such, within this narrower application it has a richer set of operators, and should be a fair bit faster (millions of messages/sec/core). Second, this has support for time-series analysis of ordered streams, either historical or in real time. The input for either type of analysis can be normal sequences, core.async channels, or Lamina channels. At Factual we use this for aggregations across many of our real-time systems, and I also use it for both ad hoc queries and daily rollups of logs and other historical data. On a personal note, I think this is one of the most interesting and useful libraries I've written. I'm really looking forward to seeing how people use it, and encourage feedback on how to make it better. Zach [1] http://www.infoq.com/presentations/analyze-running-system [2] http://vimeo.com/45132054#! [3] https://github.com/addthis/stream-lib -- -- 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.
Re: [ANN] Jig
Hey Malcolm,
*A)* Ok, so just playing around with jig some more. I'm looking to get
working *Compojure* and *Pedestal* examples.
*B)* I started with a raw `*git clone g...@github.com:juxt/jig.git*`. Then
in that directory, I ran the commands in blue.
*C)* Now, I run my environment in a Virtual Machine. So when using the
browser to try and go to each of the url end points, I got an *HTTP 404*, *Not
Found* error for all of these URLs. Ie, Compojure and Pedestal were
running, giving me HTTP responses. They just weren't giving me the
advertised endpoints, only 404s. This corresponded errors I was
experiencing when I tried to stitch in one of my simple compojure handlers
in a separate jig. There's probably some small config I'm missing, before
this becomes reeeally useful. Can't wait :)
- http://172.16.210.128:8091/server
- http://172.16.210.128:8001/readme
- http://172.16.210.128:8001
$ *lein repl*
nREPL server started on port 59398 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Welcome to Jig!
(go) -- start the system
(reset)-- reset the system
(refresh) -- recover if a reset fails due to a compilation error
(menu) -- show this menu again
Jig user *(go)*
INFO jig.system - Starting the system
INFO jig.system - Starting component ':test-ring-handler'
INFO jig.system - Starting component ':compojure'
INFO jig.system - Starting component ':jetty'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8091
http://SelectChannelConnector@0.0.0.0:8091*
INFO jig.system - Starting component ':console/server'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8001
http://SelectChannelConnector@0.0.0.0:8001*
INFO jig.system - Starting component ':console/web'
INFO jig.system - Starting component ':console/readme'
:ready
Jig user INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /web*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /web}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /readme*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /readme}
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Sun, Oct 27, 2013 at 4:39 AM, Chris Zheng z...@caudate.me wrote:
Thanks Malcom,
Even something really simple like showing your current project setup would
be really good for me to get going.
On 21/10/2013, at 15:57, Malcolm Sparks malc...@juxt.pro wrote:
Hi Chris, yes I will try to do something like that very soon.
On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote:
Would it be possible to put up a video of a typical workflow example with
pedestal. It's quite difficult for me to piece everything together just by
reading the documentation.
Chris
--
--
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.
Re: [ANN] Jig
Ok, I actually got the compojure example working. I just had to remove the
*config/console.edn* and *config/default.edn* files in my jig. They must be
disrupting the config that I put in. So that's my only feedback so far.
Ok, this is looking really good. Great work :)
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Sat, Nov 2, 2013 at 7:05 PM, Timothy Washington twash...@gmail.comwrote:
Hey Malcolm,
*A)* Ok, so just playing around with jig some more. I'm looking to get
working *Compojure* and *Pedestal* examples.
*B)* I started with a raw `*git clone g...@github.com:juxt/jig.git*`.
Then in that directory, I ran the commands in blue.
*C)* Now, I run my environment in a Virtual Machine. So when using the
browser to try and go to each of the url end points, I got an *HTTP 404*,
*Not Found* error for all of these URLs. Ie, Compojure and Pedestal
were running, giving me HTTP responses. They just weren't giving me the
advertised endpoints, only 404s. This corresponded errors I was
experiencing when I tried to stitch in one of my simple compojure handlers
in a separate jig. There's probably some small config I'm missing, before
this becomes reeeally useful. Can't wait :)
- http://172.16.210.128:8091/server
- http://172.16.210.128:8001/readme
- http://172.16.210.128:8001
$ *lein repl*
nREPL server started on port 59398 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Welcome to Jig!
(go) -- start the system
(reset)-- reset the system
(refresh) -- recover if a reset fails due to a compilation error
(menu) -- show this menu again
Jig user *(go)*
INFO jig.system - Starting the system
INFO jig.system - Starting component ':test-ring-handler'
INFO jig.system - Starting component ':compojure'
INFO jig.system - Starting component ':jetty'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8091
http://SelectChannelConnector@0.0.0.0:8091*
INFO jig.system - Starting component ':console/server'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8001
http://SelectChannelConnector@0.0.0.0:8001*
INFO jig.system - Starting component ':console/web'
INFO jig.system - Starting component ':console/readme'
:ready
Jig user INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /web*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /web}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /readme*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /readme}
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Sun, Oct 27, 2013 at 4:39 AM, Chris Zheng z...@caudate.me wrote:
Thanks Malcom,
Even something really simple like showing your current project setup
would be really good for me to get going.
On 21/10/2013, at 15:57, Malcolm Sparks malc...@juxt.pro wrote:
Hi Chris, yes I will try to do something like that very soon.
On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote:
Would it be possible to put up a video of a typical workflow example
with pedestal. It's quite difficult for me to piece everything together
just by reading the documentation.
Chris
--
--
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
Re: Functions using locks are slowed even when locks are never taken
Hmm, it seems like if it were JIT related you'd see the same issue with java code, but I get 5ns across the board. https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote: Verified that I receive the same result patterns as you on my machine. One other possibility outside of what you have already mentioned would be something JIT-related. Perhaps there is an optimization that can be performed if the locking sections of the code are in another function but otherwise no, but I'm not sure how that dovetails with Clojure' fn compilation. On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote: Since 1.6 alpha is out, I reran the tests with that -- basically the same results. On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns Execution time sample std-deviation : 0.718382 ns Execution time std-deviation : 0.729431 ns Execution time lower quantile : 24.837925 ns ( 2.5%) Execution time upper quantile : 27.595781 ns (97.5%) Overhead used : 1.634996 ns Found 4 outliers in 60 samples (6.6667 %) low-severe 2 (3. %) low-mild 2 (3. %) Variance from outliers : 15.7591 % Variance is moderately inflated by outliers done benching -- -- 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
Re: Clojure + jarjar to avoid dependency conflicts
+1 Any clojure users have any luck with jarjar? On Tuesday, 6 March 2012 15:27:52 UTC-8, nathanmarz wrote: I've been playing around with the jarjar tool ( http://code.google.com/p/jarjar/ ) in order to package my jar to avoid dependency conflicts with other libs. It doesn't seem to work though with Clojure-created classfiles, even when using aot compilation. At runtime, when doing a require/use it still tries to load the old classname and not the new classname substituted by jarjar. Has anyone had success with jarjar/clojure? -- -- 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.
