It will be, yeah. I'm benchmarking using nodejs and v8 on the command line though.
-J On Mon, Dec 26, 2011 at 2:29 PM, Michael Schwartz <[email protected]> wrote: > 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 -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
