Re: CPU & platform for best compilation performance
Thanks for the response! Isn't that change already active in I noticed the change in 0.5.13? I actually tried that release, but it did not make a difference for me. I still need to have the DevTools visible, with "Disable cache" flagged in the Network Panel, to avoid situations where a modification that was correctly picked up by Figwheel, would suddenly get lost again when I perform a hard refresh of the page. (I never fully investigated this issue, because I assumed that it was perhaps linked to the fact that I have to disable the "reload-clj-files" for CLJC-files, to avoid that a single change in a CLJC would cause a full recompile of all CLJS files — which is unmanageable if half your codebase consists of CLJC files...). -- 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/d/optout.
Re: CPU & platform for best compilation performance
Thanks, appreciated! Compiling the CLJ side takes about 30 seconds, a non-optimized CLJS about 60 seconds, and an optimized CLJS about 120 seconds. I am very well aware that these absolute numbers are not so high, at least compared to languages such as Scala. However, I perform recompilations several times per day, and this adds up. What adds up even more, is the time it takes for Chrome to perform a hard refresh of the page (about 6 seconds), which happens many many more times per day. Funny that you mention large namespaces as a possible problem, because I personally had the impression that in a Figwheel environment, having less-but-somewhat-bigger namespaces was actually preferable to having more-but-smaller namespaces. FYI: I currently have about 200 CLJS/CLJC namespaces, differing in size between 50-800 lines on average. The total amount of CLJS/Javascript code loaded during development is about 20 MB — which doesn't seem out of the ordinary, right? -- 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/d/optout.
CPU & platform for best compilation performance
Hi all,
My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
code, and compilation times are starting to interfere with my workflow
happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
to the high number of separate namespaces loaded through Figwheel.
My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For
quite a while I have been investigating whether a switch to another machine
and/or platform would be interesting from a workflow speed point of view.
However, aside from Timothy Pratley's article on the AMD Ryzen 1800x
(http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html),
I have trouble finding information that is relevant for us Clojure
programmers.
I would summarize my research as follows:
* single-core performance is most important, so that it is probably the
case that a 4-core CPU with a higher single-thread speed is preferable to
an 6/8/10-core CPU with a slower single-thread speed;
* as from 4 cores, there are hardly any speedups to be expected for having
more cores in CLJ or even (parallel) CLJS builds;
* the Ryzens are great value, but their single-core performance is usually
10-20% below the top of the line Intels;
* according to the many Phoronix benchmarks, Linux and OSX have about the
same performance, although there are some interesting deviations for some
workflows (even up to 30 - 40%);
* the single-core performance difference between my current CPU and the
single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be
between 20-40%
While a 50% performance increase would be enough to warrant the time
investment & cost of switching, my fear is that the real-world speed-up
will probably be more like a meager 20%.
Ignoring cost considerations and performance outside CLJ development: what
CPU and platform would you recommend?
Many thanks!
Maarten
--
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/d/optout.
Re: Spec & test.check generators for complex data structures
Thanks - the start of that thread was indeed interesting, but it quickly changed course towards a discussion on whether Spec should check function outputs. Rich hinted at exactly the kind of in-depth discussion I wanted to find — but much too briefly... -- 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/d/optout.
Spec & test.check generators for complex data structures
Completely convinced of Spec, I am diving into property-based testing with test.check. However, I encounter some difficulties for which I would like to get the community's input. The central part of the software I am developing, consists of a tree of different kinds of nodes that can refer to — and interact with — each other. There are many business rules that specify how those nodes can interact — e.g., a node of type A can refer to other nodes of types B and C (but not D); or a node can have max. 3 child nodes of type E but more than 3 child nodes of type F. It is trivial to have Spec generate completely random nodes to test functions that can ignore the business rules. However, other functions do depend on the business rules, and for those it is necessary to somewhat "guide" the generators towards random-but-compliant output. And here I'm stumbling: due to the business rules' complexity, this is not a matter of simply inserting a few such-that generators, so that I have already spent many days on writing a business rule compliant generator. Part of this is due to the multitude and complexity of the business rules, part due to the difficulty of writing generators (which operate at a higher level of abstraction, and for which only a subset of the normal Clojure constructs can be used). How do others cope with this issue? I have the feeling that I am pushing the generators far beyond what they were designed to do, but at the same I have to acknowledge that the time required to write traditional tests for functions dealing with the business rules is also substantial — so maybe the time required to write those generators is not abnormal. Any suggestions are welcomed! I did not find any in-depth observations of other developers about property-based testing on the Net. Maarten -- 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/d/optout.
Re: Thoughts on clojure.spec
I would also truly appreciate instrumentation of function outputs for manual outputs. I understand the rationale for not having it as the default, but could it perhaps be specified as an option s/instrument? (Considering that it was present in the first alphas, I would assume that such option should not be far-fetched.) -- 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/d/optout.
Recursive specs & forward declarations
Hi, I am struggling with recursive Spec declarations, more in particular how two Spec definitions can refer to each other. In the example below, I use a "forward" declaration, but that does not seem very elegant. Am I missing something? The more fundamental question, however, is how to implement recursion limits. After several recursive iterations during generation, I would like to force the use of non-recursive elements (leafs in the example below), to avoid stackoverflows. However, I am struggling to see how a recursion limit can be implemented. Example code: ; "Forward" declarations of specs (s/def ::Tree ::s/any) (s/def ::Leaf ::s/any) (s/def ::name string?) (s/def ::children (s/coll-of (s/or :tree ::Tree, :leaf ::Leaf))) (defrecord Tree [name children]) (defrecord Leaf [name]) (s/def ::Leaf (s/with-gen (s/keys :req-un [::name]) #(gen/let [name (s/gen ::name)] (->Leaf name (s/def ::Tree (s/with-gen (s/keys :req-un [::name ::children]) #(gen/let [name (s/gen ::name) children (s/gen ::children)] (->Tree name children When trying to generate a Tree (gen/generate (s/gen ::Tree)), a Stackoverflow is produced. I am aware of a bug report (http://dev.clojure.org/jira/browse/CLJ-1964), but that report was closed by Alex Miller due to the changes in Alpha8. (BTW, the sample code in that bug report still produces a stackoverflow in Alpha8, despite Alex' suggestion that it should now work). Any ideas? Best regards, Maarten -- 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/d/optout.
