Assigning double values to properties in V8 (e.g. r1.x = 2.5) currently
requires a small heap allocation to hold the boxed double value. You may
want to consider using WebGL Float64Array to store your persistent x/y
pairs. WebGL arrays don't box double values, however, they are more
expensive to allocate and so you likely will want to pool them.

You may also want to take a look a some of the publicly-available
JavaScript math libraries that also do math, like
closure'<http://code.google.com/p/closure-library/>s
matrix and vector support or TDL <http://code.google.com/p/threedlibrary/>.

Danno

On Mon, Dec 26, 2011 at 5:33 AM, Michael Schwartz <[email protected]> wrote:

> Going from your code linked below…
>
> You are referencing r1.x, r1.y, r2.x, and r2.y more than once.  You should
> dereference those into local variables.
>
> You are referencing this.contacts a few times.  You should dereference it
> at the top, e.g. var contacts = this.contacts;
>
> You are accessing this.contacts.length, which is not optimal from all the
> stuff I've read on the WWW.  To make it worse, you're doing it in a loop.
>
> Something like:
>
> var contacts = this.contacts;
> for (var i=0, clen=contacts.length; i<len; i++) {
>  …
>
>
> Might gain you some performance gains.
>
> Where you calculate the same value more than once,
>
>               var bias_x = n.x * (con.jBias - jbnOld);
>               var bias_y = n.y * (con.jBias - jbnOld);
>
> con.jBias - jbn0ld
>
> You might be able to calculate that once, saving you a subtract operation 
> once per loop.  It could be quite a gain, actually.  Consider:
>
> var x = '1';
> x += 1;
> (results string concatenation, value '11')
> var x = 1;
> x += 1;
> (results in integer, value 2)
> It's doing something like typeof(x) to figure out whether to do addition or 
> concatenation.
>
> Merry Christmas.
>
>
> On Dec 25, 2011, at 7:27 PM, Joseph Gentle wrote:
>
> Cool - well, from inlining a bunch of vectors, and some other minor
> tweaks I've nearly doubled performance. Its still >3x worse than the
> original C implementation though, so I think I can do better. Brendan:
> local numbers should be stored on the stack, right?
>
> According to this profiling run: https://gist.github.com/1520465 :
>
> I'm spending 45% of my time in this javascript function:
>
> https://github.com/josephg/Chipmunk-js/blob/master/lib/cpArbiter.js#L349-406
>
> Even a 2% improvement in that one function there would be noticable.
> Any ideas on how I can improve it? (The array I'm looping over usually
> only has one element, if that helps).
>
> I'm also spending 10% of my time in this C++ function:
> v8::internal::SemiSpaceIterator::Next
> What is that? Can I do less of it?
>
>
> I really appreciate the help - physics in the browser is fun! -
> http://dl.dropbox.com/u/2494815/code.html
>
> -Joseph
>
>
> On Mon, Dec 26, 2011 at 6:08 AM, Brendan Miller <[email protected]>
> wrote:
>
> I could be wrong, but I think I asked on this list earlier, and locals
>
> are not necessarily stored on the stack because they can be captured
>
> by a nested function. So, depending on how much you use closures,
>
> inlining might not solve your problem.
>
>
> On the other hand a simple free list would make a lot of sense and
>
> would presumably lead to more readable code. Certainly, this is what
>
> I'd do in C or C++ if I wanted to reduce allocation and deallocation
>
> time. In javascript, the effect would be a little bit different. On
>
> the first compaction, I think you wouldn't save much time, but once
>
> your vectors got promoted into the "old" generation, they'd see fewer
>
> compactions.
>
>
> I'm not a v8 developer though and don't know the internals of the GC,
>
> except that it is generational.
>
>
> On Sat, Dec 24, 2011 at 10:48 AM, tjholowaychuk <[email protected]>
> wrote:
>
> I would inline most of the simple ones personally, or even maybe add a
>
> build step and use some kind of macro
>
>
> On Dec 24, 1:37 am, Joseph Gentle <[email protected]> wrote:
>
> I'm porting a physics engine (chipmunk!) from C to javascript. Internally,
>
> chipmunk uses 2d vectors pretty extensively. In C, they're a simple struct
>
> passed by value. In javascript, my vectors are being allocated on the heap.
>
>
> I did some benchmarks - in 5 seconds, chipmunk-js allocates about 20
>
> million vectors. The simulation spends about a third of its time in the
>
> garbage collector. (Eep!).
>
>
> I would move across to simply storing x and y values, but a lot of the
>
> vector manipulation functions need to return new vectors. (Eg, add(),
>
> mult(), rotate(), lerp(), ... etc). If I store (x,y), I need a way to
>
> return two values from those functions.
>
>
> My ideas:
>
> - Try and use an object pool of vectors. It might be hard to track the
>
> lifetime of all the vectors the library uses, but I should be able to
>
> manually release most of them.
>
> - Make all the functions that return a vector instead store the (x,y) pair
>
> in a pair of global variables. Other functions can then copy the result
>
> back when they're done computing. That way, I can remove heap-stored
>
> vectors entirely; though my code will get super messy.
>
> - Manually inline a lot of the vector functions. Again, my code will get
>
> messier.
>
>
> What do you guys reckon? Are there any other options?
>
>
> My trivial vector implementation is here:
> https://github.com/josephg/Chipmunk-js/blob/master/lib/cpVect.js
>
>
> -J
>
>
> --
>
> v8-users mailing list
>
> [email protected]
>
> http://groups.google.com/group/v8-users
>
>
> --
>
> v8-users mailing list
>
> [email protected]
>
> http://groups.google.com/group/v8-users
>
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>
>
>  --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to