On Apr 12, 2012, at 1:24 AM, Marco Rogers wrote:
> I would've hoped you had more fortitude against the attacks on streamline
> then to start throwing around hastily designed benchmarks to prove your
> point. It sucks that the "sync-looking" advocates have to deal with the level
> of aggression they do here. I've expressed that to some people myself, even
> though I don't advocate these solutions either. But this is almost certainly
> not the way to win hearts and minds.
>
> When you create an abstraction layer, it's almost always slower. That's just
> something you're not going to get away from.
That's wrong, StreamLined code does not have to be any slower because it simply
writes the JS for you:
> On Apr 10, 2012, at 10:35 PM, Bruno Jouhier wrote:
>
>> Streamline translates its special syntax to vanilla JS with callbacks. So,
>> if you implement a function like
>>
>> function foo(x, y, _) { ... }
>>
>> Normal JS modules (not written with streamline) will be able to call it as:
>>
>> foo(x, y, function(err, result) { ... });
>>
>> Streamline is just a tool that helps you write your code. This tool produces
>> vanilla JS that follows the standard node callback conventions. So you can
>> publish it to NPM, you won't be forcing anyone else to use streamline. (...)
> On Apr 10, 2012, at 11:01 PM, Axel Kittenberger wrote:
>>
>> Its not like Bruno is doing an evil plot here. Since as long your
>> benchmark does not compare apple with oranges, it will always be just
>> as fast as vanilla written code, since in the end, it translates to
>> vanilla code.
> Even if the benchmark wasn't flawed, simply because you can contrive a
> scenario where it wins doesn't make up for the fact that it stills loses most
> of the time.
Again, wrong. It simply writes for you the ~ exact vanilla JS code you would
have had to write yourself.
> Then on top of that, it becomes clear that streamline does some trickery in
> transforming to js that injects more cleverness. Hence the fact that your
> example doesn't require an explicit nextTick. So then you leave people with
> the feeling that if it is ever faster, it's because streamline has done some
> tricky optimizations in the background.
Totally safe optimizations, as any other good compiler would do. Is that a bad
thing too, in your opinion?
> In my opinion, people who are interested in streamline and fibers will
> already be prepared to take the performance hit in exchange for ease of use.
Please stop with "the performance hit" bs, thanks.
> A better argument would be that you're committed to making that hit as small
> as possible. And assuring people that a 2x difference won't often make a huge
> difference in practice.
You're making up numbers.
> I agree with that, and I think it's easily defensible.
Only if it were true, which it isn't.
> This benchmark is not.
FYI the benchmark is a reply to this:
> On Apr 10, 2012, at 4:55 PM, Joe Ferner wrote:
>> On Apr 10, 10:12 am, Bruno Jouhier <[email protected]> wrote:
>>> @joeferner
>>>
>>> (...) From my experience there are code patterns where fibers beats
>>> callbacks 10 to 1.
>>
>> beats 10 to 1 how? in code readability?
--
Jorge.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
