Thanks; I'll do that. I assume v8 doesn't make optimized versions of
classes - which could take advantage of the fact that certain properties
are always floatingpoint values (and hence remove the need for the heap
allocations).
Is the same also true for functions? Ie, if I have:
function foo(x) { ...}
Will calling foo(123) cause a heap allocation?
Cheers
-Joseph
On Tuesday, 27 December 2011 20:42:26 UTC+11, danno wrote:
>
> 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
