On 8/21/06, Brian Beck <[EMAIL PROTECTED]> wrote: > > I profiled some code using MochiKit's functional tools versus the > normal JavaScript programming style: > http://blog.case.edu/bmb12/2006/08/functional_programming_in_javascript_nice_but_slow > > I'm not complaining or anything, just wondering if my thoughts on the > cause of the performance difference is accurate... any ideas?
Yes, that's pretty much expected. The overhead here is function call dispatch... if your code did something more substantial in the loops, then it would be less significant. The implementation you're using also makes a difference, but you don't mention which JavaScript VM you're using nor which version or platform so your benchmarks aren't very easily verifiable. The code in MochiKit.Iter is certainly going to be the slowest of the bunch because it's hyper-generalized to work with iterators and very few parts have a fast-path for arrays. Work could be done to add some fast paths, and patches for that would likely be accepted. The code in Base is mostly as fast as can be expected though, but there are probably small wins that could be gained here and there by profiling various different techniques. Using abstraction in JavaScript without some kind of optimizing precompiler always executes slower than writing stuff out by hand, but it's faster to use abstract forms than to write everything out all the time. It's up to you to decide whether a given part of an application needs to be *developed* quickly, or if it must *execute* as quickly as possible. -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~----------~----~----~----~------~----~------~--~---
