>
> 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
On Thu, Apr 12, 2012 at 1:13 AM, Brandon Bloom wrote:
>
> In my little test project (which depends on Vars for some clever DOM
> manipulation callbacks), I needed a way to get the :dynamic flag when
> attaching a REPL to an already-compiled front end. What I did was prn the
> namespaces atom to t
>
> 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
Awesome work!
> 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.
>
I encountered something similar when implementing bound-fn and friends
(see: https://github.com/brandonbloo
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
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 see what special techniques (if any) are needed to get hand-coded
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
It's now possible to write CLJS that has the exact same performance as
handwritten JS - I compared the handwritten JS s
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, these can be seen her
12 matches
Mail list logo
