Yup, it is a known issue. See http://dev.clojure.org/jira/browse/CLJS-1954.
On Friday, March 3, 2017 at 2:44:52 PM UTC-8, Chad Harrington wrote:
>
> I believe that cljs versions 1.9.493 and above break core.async (and
> possibly other libraries) under :advanced optimizations.
>
I believe that cljs versions 1.9.493 and above break core.async (and
possibly other libraries) under :advanced optimizations.
Here is a minimal reproduction:
In src/ca_adv_bug/core.cljs:
(ns ca-adv-bug.core
(:require
[cljs.core.async :as ca]
[cljs.nodejs :as nodejs])
(:require-macros
many namespaces? How do I tell
> the main module to use all of them? Do I have to list them ALL?
>
>
> On Friday, February 19, 2016 at 5:54:59 PM UTC+2, William la Forge wrote:
>>
>> Compiling with optimizations none is no doubt quite handy, especially in
>> conjunctio
:
>
> Compiling with optimizations none is no doubt quite handy, especially in
> conjunction with source maps, as a traceback will take you to the line of
> code causing the problems, and with the same variable names used in your
> original clojurescript code. But this is not currently p
I should mention here that if you are tuning the GC anywhere except at the
end of your development cycle you're probably doing it wrong. 99% of the
time you'll get better performance by reviewing your algorithms, running a
CPU profiler, generating less garbage (via transients or something like
that
I've found Censum by jClarity to be an excellent tool to tune JVM GC
parameters to your specific application running on a particular server. You
add a few GC parameters to enable logging that the tool needs, run your app
under load for enough time to get sufficient data, and then feed the log
direc
GC parameters used by a lot of projects are handed down like traditions for
years, even spreading to others. They're almost never re-evaluated, which means
they might actually lose out on new performance improvements, or worse, might
even cause performance regressions.
Most parameters in the Ov
:
>
> Following this thread:
> http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world
>
> I was wondering if anybody has some experience regarding GC optimizations
> that would work better for Clojure than the default: stop-the-world
> approach.
Following this thread:
http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world
I was wondering if anybody has some experience regarding GC optimizations
that would work better for Clojure than the default: stop-the-world
approach.
My point being that given
Hey,
I have seen Servant but I do not like it. In general I do not like
solutions that use macros to solve problems a build tool should solve. YMMV.
cljs-runtime is the directory used by shadow-build for all compiled files.
The structure it creates is that you have one directory, with a .js fil
Thomas,
Your worker demo includes the entire cljs runtime as part of the
project?
https://github.com/thheller/worker-example/tree/master/demo/js/cljs-runtime
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloju
Thomas,
Have you seen this? A simple demo using workers in
clojurescript: https://github.com/MarcoPolo/Servant
I've converted the demo to use
boot: https://github.com/aatree/aademos/tree/master/servant-demo
--
You received this message because you are subscribed to the Google
Groups "Clojure"
Thomas,
Modules looks quite exciting. I would be glad to help in developing a boot
task for same.
Bill
--
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 a
make the point that web
workers should *ALWAYS* be used via closure modules, it is just the most
efficient way to organise the code and output.
Just my 2 cents,
/thomas
On Friday, February 19, 2016 at 4:54:59 PM UTC+1, William la Forge wrote:
>
> Compiling with optimizations no
Compiling with optimizations none is no doubt quite handy, especially in
conjunction with source maps, as a traceback will take you to the line of
code causing the problems, and with the same variable names used in your
original clojurescript code. But this is not currently possible for .jc
That's it! Thanks so much for the help! In what cases is a function
turned into a RestFn? variadic clojure or vararg java? I was confused
about how clojure is turned into java, but things are a little clearer now.
(make-array) uses java.lang.reflect.Array.newInstance, which is bad as
well.
Offhand it looks like the only RestFn you call from filter-link is
clojure.core/format. Have you tried replacing that with something like this?
(String/format (.get link 1) (doto (make-array String 1) (aset 0 (.get link
2)))
I'm not suggesting that's idiomatic, but if it addresses the issue then
On Tuesday, June 18, 2013 9:58:20 AM UTC-7, Michael Klishin wrote:
>
> 2013/6/18 Tim Jones >
>
>> How do I get to near-java performance?
>
>
> Start by providing a snippet of your code and profiling.
>
> Great. Here's the context: iterate through a list of Product, and for
each Product, get a L
Let's try this again. Maybe the question is what is the most performant
way to consume a native java collection (List, array, or other) in clojure?
What I've tried so far hits clojure-imposed performance issues. How do I
get to near-java performance? I'm trying to create a polemic for clojur
2013/6/18 Tim Jones
> How do I get to near-java performance?
Start by providing a snippet of your code and profiling.
Most likely you are hitting either boxing or extra method calls that are
not obvious from the code.
But nobody can tell if that's really the case, esp. without seeing the
actua
I'm working on a small clojure program which pulls data from a custom
memory-backed data store via a java api. When looking at performance,
there is a hotspot at the point of interaction with this API. One of the
fields of each record being exported contains a list of lists of strings
(List>)
>
> Why not just analyze the source path? Also re-analyze changed files?
>
That would probably work. The benefit to doing it the way I'm doing it is
that it loads the analysis results of the build that is loaded.
Imagine:
1. Write some CLJS
2. Compile it
3. Load it up in the browser
Related - dynamic binding. You will now get a warning if you try to use a
>> var that has not been declared ^:dynamic. Dynamic vars are never direct
>> invoked.
>>
>
> Have you given any more consideration to bound-fn,
> {push,pop,get}-thread-bindings, Var with IWatchable,
>
> I needed a way to get the :dynamic flag when attaching a REPL to an
> already-compiled front end
>
To clarify: You need the :dynamic flag to know now to emit a direct call.
I implemented IFn and IDeref on Var. When emitting :var, I had to check
:dynamic to see if I could emit namespace.va
are never direct
> invoked.
>
Have you given any more consideration to bound-fn,
{push,pop,get}-thread-bindings, Var with IWatchable, etc?
Now that this compiler state is required for optimizations, my Vars changes
aren't as big and scary in my mind. I'd be happy to bring the bran
It does seem like you need to use native js data structures if you want
speed. Makes sense, and it's not a big deal beyond the psychic injuries
caused by going mutable. I've had to switch from vectors/maps to
arrays/objects a few times due to performance.
- Jason
On Tuesday, April 10, 2012 3:4
Good point, fixed in master.
On Wed, Apr 11, 2012 at 11:28 AM, David Powell wrote:
>
>
> On Tue, Apr 10, 2012 at 6:21 PM, David Nolen wrote:
>
>> I've merged these changes in master. I've also added another change that
>> results in yet another large perf boost:
>>
>> - direct invocation of known
On Tue, Apr 10, 2012 at 6:21 PM, David Nolen wrote:
> I've merged these changes in master. I've also added another change that
> results in yet another large perf boost:
>
> - direct invocation of known fns instead of going through .call
>
Not sure whether this is of interest, but in IE built-in
As pointed out by Chouser and others the direct invocation does introduce a
bit of static-ness to ClojureScript.
In particular switching a top level definition from a fn to an object
(which implements IFn) can cause problems. The compiler now issues warnings
if this happens.
Related - dynamic bin
On Tue, Apr 10, 2012 at 6:23 PM, Jason Hickner wrote:
> Very cool! I'm seeing a size reduction in some code of mine that made
> extensive use of core.match. Maybe from the removal of a lot of CLJS truth
> tests?
>
> Do you have the source available to your CLJS spectral norm code? I'd like
> to s
ing some code size explosion.
>> I've committed a refactor that eliminates the issue. Please try!
>>
>> On Sun, Apr 8, 2012 at 6:26 PM, David Nolen wrote:
>>
>>> I've spend the past weekend doing some comprehensive optimizations to
>>> Clojur
8, 2012 at 8:59 PM, David Nolen wrote:
> The multi-arity fn optimization was causing some code size explosion. I've
> committed a refactor that eliminates the issue. Please try!
>
> On Sun, Apr 8, 2012 at 6:26 PM, David Nolen wrote:
>
>> I've spend the past wee
The multi-arity fn optimization was causing some code size explosion. I've
committed a refactor that eliminates the issue. Please try!
On Sun, Apr 8, 2012 at 6:26 PM, David Nolen wrote:
> I've spend the past weekend doing some comprehensive optimizations to
> ClojureScript, t
I've spend the past weekend doing some comprehensive optimizations to
ClojureScript, these can be seen here:
https://github.com/clojure/clojurescript/compare/all-optimizations
With these optimizations operations are anywhere from 1.5X-5X faster
depending on the operation and the JavaS
ipt) and I'm really enjoying
> it.
> > I'd love to use it for a project but I have one major concern: How
> reliable
> > is {:optimizations :advanced}?
> >
> > Advanced Compilation basically wins the whole argument for clojurescript
> but
> > I ma
/ibdknox/jayq/blob/master/resources/externs/jquery.js
On Sun, Feb 5, 2012 at 11:39 AM, Thomas Heller wrote:
> Hey,
>
> I'm starting to get the hang of Clojure(Script) and I'm really enjoying it.
> I'd love to use it for a project but I have one major concern: How reliable
>
Hey,
I'm starting to get the hang of Clojure(Script) and I'm really enjoying it.
I'd love to use it for a project but I have one major concern: How reliable
is {:optimizations :advanced}?
Advanced Compilation basically wins the whole argument for clojurescript
but I managed t
Hmm I seemed to have figured it out. Calling memo-lru on the handler was
not a good idea since there are elements that change with each request,
therefore all calls were a cache miss. Also I, I can't wrap memo-lru on a
function that outputs a bytearrayinputstream since that object has state. I
I'm dynamically generating images for a website and I'm hosting the content
using ring. Currently I use moustache for routing, where I have a handler
that returns a response map and the response map contains a
bytearrayinputstream. Currently I wrap the handler that makes the image
file with mem
Mode does some
optimizations like inlining. In practice, probably not much, because a
good JavaScript interpreter will do the same optimizations at runtime.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, se
I haven't seen performance gains from advanced optimization.
David
On Thu, Nov 17, 2011 at 5:18 PM, Paul Richards wrote:
> Hi,
> I'm interested in the differences between the default ClojureScript
> compile, and the {:optimizations :advanced} mode.
>
> Aside from loadin
Hi,
I'm interested in the differences between the default ClojureScript
compile, and the {:optimizations :advanced} mode.
Aside from loading times (due to different file sizes) and memory
usage (again due to different file sizes, minified field names, etc),
do we expect the optimized versi
It looks like this would be relevant to Clojure, seeing as we use final
fields all over the place, anyone have any ideas about it?
http://www.azulsystems.com/blog/cliff/2011-10-27-final-fields-part-2
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
T
Thank you for sharing your eventual solution. For the future, the
Google Closure library reference is at
http://closure-library.googlecode.com/svn/docs/index.html
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to c
I think I got the reason.
I should use goog.net.xmlhttpfactory instead of goog.net as required
namespace.
On 8月4日, 下午9时41分, sunng wrote:
> Hi all,
>
> I have a problem when compiling my code into optimized js:
> Aug 04, 2011 9:34:10 PM
> com.google.javascript.jscomp.LoggerErrorManager println
> S
Hi all,
I have a problem when compiling my code into optimized js:
Aug 04, 2011 9:34:10 PM
com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /home/sun/projects/rageviewer/out/rageviewer/utils.js:3: ERROR
- required "goog.net" namespace never provided
goog.require('goog.net');
Dear fft1976,
On Fri, 2009-08-14 at 17:16 -0700, Jarkko Oranen wrote:
>
> I don't think spending too much effort on the compiler at this point
> is useful. It will eventually be rewritten in Clojure anyway, and Rich
> has stated that he is more interested in architectural improvements
> rather
fft1976 wrote:
> On Aug 13, 9:57 pm, Daniel Lyons wrote:
>
> > the code is open source and the techniques for adding
> > optimizations to compilers are well known. So marshall your impulses
> > for the good and we'll all benefit.
>
> It does seem that the
On Aug 13, 9:57 pm, Daniel Lyons wrote:
> the code is open source and the techniques for adding
> optimizations to compilers are well known. So marshall your impulses
> for the good and we'll all benefit.
It does seem that the optimizations Andy Fingernut did by hand are
pr
Hi all.
Recently started to optimize two models written in clojure, and I
could use some tips from you guys.
I first enabled the set reflection-warning thing, and removed
reflections in the inner loop of my program. That already helped a
lot, speeding up the whole thing to about 40% of its origi
50 matches
Mail list logo
