Interesting. So have you found bind() to be more or less efficient than
.call() and or .apply()?
AJ ONeal
On Fri, Jun 8, 2012 at 3:48 PM, Jimb Esser <wastel...@gmail.com> wrote:
> Technically, at least in V8, .bind is a lot lighter weight than an
> anonymous function. There are a large number of micro-benchmarks to look
> at on jsperf.com, but for an actual anecdote, at one point we
> accidentally required in a module which overrode Function.prototype.bind
> with something that created an anonymous function (some browser-support
> code for pre-.bind browsers), and our performance tanked, garbage
> collection times increased significantly.
>
>
> On Fri, Jun 8, 2012 at 2:25 PM, AJ ONeal <coola...@gmail.com> wrote:
>
>> If I'm not mistaken, bind() has the same technical drawbacks as using an
>> anonymous function (higher memory usage, more garbage collection, and
>> slower says Tim), but it does solve the maintainability / prettiness issue.
>>
>> I just want to point out that Raspberry Pi is now shipping.
>> NodeJS is a very attractive option for development.
>>
>> My own experience with my ARM-based media server has lead me to be a
>> believer in prototypes and leaner code. I can't say that one little anony
>> here and there is going to blow up an application, but I know for a fact
>> that there are significant performance gains when they are avoided.
>>
>> I know it doesn't seem like a big deal now. But one day you may change
>> your mind.
>>
>> AJ ONeal
>>
>> On Fri, Jun 8, 2012 at 2:22 PM, George Stagas <gsta...@gmail.com> wrote:
>>
>>> No need to change the API, we have .bind() - use the language
>>> features, don't reinvent them.
>>>
>>> 2012/6/8 Tim Caswell <t...@creationix.com>:
>>> >
>>> >
>>> > On Fri, Jun 8, 2012 at 2:10 PM, tjholowaychuk <tjholoway...@gmail.com>
>>> > wrote:
>>> >>
>>> >> what's wrong with .bind() ?
>>> >>
>>> >
>>> > Mainly the overhead. Bind creates a new function every time it's
>>> called,
>>> > and calling the bound function is a bit slower, especially in V8.
>>> (Insert
>>> > statement about performance only mattering if it's significant...)
>>> >
>>> > I usually will bind all my methods from the prototype that will be
>>> used as
>>> > callbacks to the instance itself inside the constructor. This gives
>>> me a
>>> > ton more "own" properties, but otherwise is fairly elegant.
>>> >
>>> >>
>>> >> On Jun 8, 11:52 am, AJ ONeal <coola...@gmail.com> wrote:
>>> >> > emitter.on('data', myModule.dataHandler, myModule);
>>> >> >
>>> >> > Even if myModule were to subclass EventEmitter, wouldn't I still
>>> need to
>>> >> > pass in the `myModule` instance so that I get the correct `this`? I
>>> >> > don't
>>> >> > think I understood what you meant by that.
>>> >> >
>>> >> > And then these cases as well:
>>> >> >
>>> >> > fs.readFile(file, encoding, myModule.fileHandler, myModule);
>>> >> >
>>> >> > process.nextTick(myModule.tickHandler, myModule);
>>> >> >
>>> >> > The list goes on. Obviously not a small project. Not difficult
>>> either,
>>> >> > just
>>> >> > tedious.
>>> >> >
>>> >> > AJ ONeal
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Jun 8, 2012 at 12:42 PM, Tim Caswell <t...@creationix.com>
>>> >> > wrote:
>>> >> > > Actually event emitters already call in the scope of the emitter,
>>> so
>>> >> > > there
>>> >> > > is no need for a specific "this" value there. Just subclass
>>> >> > > EventEmitter
>>> >> > > and use normal methods.
>>> >> >
>>> >> > > On Fri, Jun 8, 2012 at 1:34 PM, AJ ONeal <coola...@gmail.com>
>>> wrote:
>>> >> >
>>> >> > >> If you're going to use `this` then you must have a callback. It
>>> would
>>> >> > >> make no sense to have a `this` and nothing to apply it to.
>>> >> >
>>> >> > >> You think EventEmitters would feel the overhead of the if?
>>> >> >
>>> >> > >> // context is Array, Object, or Function.
>>> >> > >> // Numbers, Strings, and Booleans need not `apply` (very
>>> punny)
>>> >> > >> if (context) {
>>> >> > >> fn.call(context, a, b, c);
>>> >> > >> } else {
>>> >> > >> fn(a, b, c);
>>> >> > >> }
>>> >> >
>>> >> > >> As far as the guesswork, well, I hear you on that. I've already
>>> done
>>> >> > >> my
>>> >> > >> ranting at UtahJS Conf. Put this as one more in the bucket of
>>> reasons
>>> >> > >> that
>>> >> > >> callbacks-last was not a well-thought out idea....
>>> >> >
>>> >> > >> AJ ONeal
>>> >> >
>>> >> > >> On Fri, Jun 8, 2012 at 12:27 PM, Tim Caswell <
>>> t...@creationix.com>
>>> >> > >> wrote:
>>> >> >
>>> >> > >>> I think it's a useful addition, but it does cause a little
>>> overhead
>>> >> > >>> (though it's probably not noticeable compared to the actual
>>> work the
>>> >> > >>> async
>>> >> > >>> function is doing). EventEmitters might feel the pain since
>>> they
>>> >> > >>> are sync.
>>> >> > >>> I do worry that it makes things harder for our argument
>>> guessing
>>> >> > >>> code that
>>> >> > >>> assumes the last arg is a callback. Now there will be an
>>> optional
>>> >> > >>> argument
>>> >> > >>> after the callback that can be anything (including another
>>> function)
>>> >> >
>>> >> > >>> On Fri, Jun 8, 2012 at 1:18 PM, AJ ONeal <coola...@gmail.com>
>>> wrote:
>>> >> >
>>> >> > >>>> Yes, That's what I am suggesting.
>>> >> >
>>> >> > >>>> AJ ONeal
>>> >> >
>>> >> > >>>> On Fri, Jun 8, 2012 at 12:17 PM, Tim Caswell
>>> >> > >>>> <t...@creationix.com>wrote:
>>> >> >
>>> >> > >>>>> So this proposal is to modify the API of all async functions
>>> to
>>> >> > >>>>> have
>>> >> > >>>>> an extra thisp argument after the callback argument (like
>>> done in
>>> >> > >>>>> Array.prototype.forEach)?
>>> >> >
>>> >> > >>>>> On Fri, Jun 8, 2012 at 1:06 PM, AJ ONeal <coola...@gmail.com>
>>> >> > >>>>> wrote:
>>> >> >
>>> >> > >>>>>> I would like to propose that an additional parameter,
>>> `context`
>>> >> > >>>>>> be
>>> >> > >>>>>> added to core node modules that accept callbacks to give
>>> >> > >>>>>> this-ness to the
>>> >> > >>>>>> callback.
>>> >> >
>>> >> > >>>>>> The reason being is that I'm trying to eliminate anonymous
>>> >> > >>>>>> callbacks
>>> >> > >>>>>> from my code and have generally cleaner, more readable code
>>> (as
>>> >> > >>>>>> well as
>>> >> > >>>>>> lower memory usage and less garbage collection).
>>> >> >
>>> >> > >>>>>> I don't know if this has been discussed before, but I'd like
>>> to
>>> >> > >>>>>> put
>>> >> > >>>>>> it on the table.
>>> >> >
>>> >> > >>>>>> AJ ONeal
>>> >
>>> >
>>>
>>
>>
>
