On Apr 9, 6:42 am, buda wrote:
> It seems to me that this behavior should be by default and if I not
I disagree. This would raise serious performance issues. I side with
T.J. on this one.
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On Mar 15, 5:49 pm, Tobie Langel wrote:
> Thanks.
>
> I'd like the refactoring to include all Function.prototype methods,
> not just bind, so we have a clean and coherent src code.
>
> Best,
>
> Tobie
I've just created a ticket that includes a patch to as much of the
function.js stuff as seemed
On Mar 15, 8:09 am, kangax wrote:
> On Mar 15, 10:35 am, Tobie Langel wrote:
> [...]
>
> > The difficulty of abstracting your solution comes from the need for
> > the bound function to keep a reference to the original length of the
> > array so a to reset it before passing it to the original f
On Mar 14, 8:24 am, kangax wrote:
> Why not combine two?
>
> ...
> function() {
> if (arguments.length) {
> var ll = arguments.length;
> args.length = l + ll;
> while (ll--) {
> args[l+ll] = arguments[ll];
> }
> }
> return fn.apply(context, args);}
> }
This implementa
On Mar 13, 4:33 pm, Tobie Langel wrote:
> > It's this latter case where having the args array cached provides
> > significant performance benefit, which I would argue is worth doing,
> > even if it slightly lessens the performance of "someFunc()" with no
> > arguments. That's the tradeoff we're
... and it's probably worth pointing, again, to my updated performance
data on this page:
http://www.broofa.com/blog/2009/03/prototype-bind-performance/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & scr
On Mar 13, 4:33 pm, Tobie Langel wrote:
> > It's this latter case where having the args array cached provides
> > significant performance benefit, which I would argue is worth doing,
> > even if it slightly lessens the performance of "someFunc()" with no
> > arguments. That's the tradeoff we're
On Mar 13, 12:12 am, "T.J. Crowder" wrote:
> > ...I'd say it's
> > a tossup as to how often a bound function will/won't be passed
> > arguments
>
> H. That would be worth checking. I almost never use bind() with
> arguments other than the context; in fact, I don't recall the last
> time
@Kangax: That's definitely a nice improvement! I've updated my post to
include your method as well as an "Improved" method that adds my trick
for reusing the args array. The "improved" version is a little slower
when you call the bound function w/out args, but is significantly
faster (on most pla
@Tobie: "[*Evil Cackle*]... You just now noticed that, did you?"
Yeah, it's a nice little trick. And, yes, it does look a little
fishy, but I couldn't think of any reason why it wouldn't work.
I've updated the blog post to include your implementation in the
tests. (BTW, please note that if you
*Darn* 'Just noticed a bug in my test suite. I've just rejiggered the
tests and updated the blog post. The results are more varied/
intersting than before, but still show significant improvements.
better than the current prototype implementation.
Anyone care to explain the FF behavior when pass
[Wow, wasn't expecting such a barrage of (great) responses! (I get
this list in digest mode, so find myself scrambling to catch up
here.)]
Regarding performance stats: I've just posted some test data over on
my blog...
http://www.broofa.com/blog/2009/03/prototype-bind-performance
Basically, it
*dooh* sorry - shoulda just stuck that code in a Pastie, like so:
http://pastie.org/412930
FWIW, I just collected some stats on our code to determine what %'age
of cases are binding arguments .vs. just binding an object. It looks
like it's ~98.5% (2170 of 2200 calls to bind pass a single object
As I suspect is common with many Prototype shops, over here at
Zenbe.com, we're making HEAVY use of Function#bind(). We've been
using a custom version of the bind() method for a while now, and I've
recently added a couple enhancements that I'd like to get people's
opinions on - especially that o
14 matches
Mail list logo
