This code is running in the browser?

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

Reply via email to