Live data from Hacker News

uWebSockets: Scalable WebSocket server library for Node.js and C++11

github.com

41–50 of 87 posts

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#41

This looks awesome. Can I use this with Meteor? If there is any app that would benefit from websocket optimizations it's Meteor.

I don't think so but Meatier (https://github.com/mattkrick/meatier) should receive uws as default engine since it build on SC, you could look into that but honestly I don't understand this project at all :P

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#42

Earlier quoted context omitted.

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

I can understand that you might be a bit frustrated right now, because perhaps that level of performance in pure python may literally be difficult to impossible in this case. But, the question the person was asking was a very reasonable one -- something along the lines of "I'm using this solution in python right now, and I'd like more performance -- what are my options?" It seems like you not only misunderstand the q…

Toss a coin and it will land on someones holy ground..

My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#43
post #24

Earlier quoted context omitted.

yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production. EDIT: Specifically I'm referring to the usage of raw pointers, unchecked pointer arithmetic, goto for flow control and raw new/delete calls. The author says they have run tests under valgrind, but that doesn't say anything unless the inputs were malicious. Ideally it should be co…

1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x. Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it? Get over yourself.

If you want people to take you and your projects seriously, you are going to have to stop being so antagonistic. I've seen you act this way here, on Reddit, and on GitHub...

The sarcasm, childish comments, and resorting to insults the second someone criticizes your code isn't giving me any hope that you can competently maintain a project like this.

Take a look over the HN Guidelines [1] and the "Approach to comments"[2] sections of the site.

[1] https://news.ycombinator.com/newsguidelines.html

[2] https://news.ycombinator.com/newswelcome.html

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#44
post #21

Earlier quoted context omitted.

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

Because Nodejs is known to be highly performant with its single thread model...

Node.js has nothing to do with the performance of this server.

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#45
post #24

Earlier quoted context omitted.

yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production. EDIT: Specifically I'm referring to the usage of raw pointers, unchecked pointer arithmetic, goto for flow control and raw new/delete calls. The author says they have run tests under valgrind, but that doesn't say anything unless the inputs were malicious. Ideally it should be co…

1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x. Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it? Get over yourself.

There's no need to resort to insults in-reply to questions or criticisms.

It's a valid question (that i think you did answer, but not very well). Dropping to very unsafe "lower levels" should only be done when absolutely necessary as a single mistake here could cause massive security issues.

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#46
post #26

Earlier quoted context omitted.

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

"TL;DR asyncio is an asynchronous I/O framework shipping with the Python Standard Library. In this blog post, we introduce uvloop: a full, drop-in replacement for the asyncio event loop. uvloop is written in Cython and built on top of libuv. uvloop makes asyncio fast. In fact, it is at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework. The performance of uvloop-based asyncio is c…

WARNING ----> NO OFFENCE:

You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while.

This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tcp_t. This is the level of optimizations we are talking about -> when libuv is considered too heavyweight...

When libuv becomes too heavyweight to keep up, having this discussion about how a Python async network library could implement similar performance is just purely ridiculous.

WARNING -> NO OFFENCE

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#47
post #24

Earlier quoted context omitted.

yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production. EDIT: Specifically I'm referring to the usage of raw pointers, unchecked pointer arithmetic, goto for flow control and raw new/delete calls. The author says they have run tests under valgrind, but that doesn't say anything unless the inputs were malicious. Ideally it should be co…

1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x. Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it? Get over yourself.

Humility and a collaborative attitude are really important to get the best results.

When people attack your code, it isn't an attack on you. It makes your code better. It's one of the downsides to releasing any opinionated project (and many good projects are opinionated).

For my part, I won't use software written by someone who doesn't either refute criticism or use it to improve code, and I'm not satisfied you're doing either of those.

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#48

In https://github.com/alexhultman/uWebSockets/blob/master/src/u... What's the deal with delete [] (char *) head; where `head` is of type `struct Message` ? Is this some kind of performance trick ?... Otherwise it looks kind of suspicious..

Not sure if that's wrong, but it seems that the program would crash if you call pop() on an empty Queue? I guess it never happens in this particular program, which I assume was the reason to squeeze even more performance.

Yes it would cause undefined behavior but empty() is checked before popping.

Re: uWebSockets: Scalable WebSocket server library for Node.js and C++11

#50
post #47

Earlier quoted context omitted.

1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x. Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it? Get over yourself.

Humility and a collaborative attitude are really important to get the best results. When people attack your code, it isn't an attack on you. It makes your code better. It's one of the downsides to releasing any opinionated project (and many good projects are opinionated). For my part, I won't use software written by someone who doesn't either refute criticism or use it to improve code, and I'm not satisfied you're do…

According to logic, this quote "yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production." is a personal attack. I get offended by this, personally. When I get offended, personally, I answer how ever I see fit.

Thank you, you will be missed. I don't know what to do without you.

Post reply on HN