Comment by kevingadd | Hacker News Reader

Comment by kevingadd | Hacker News Reader

Parent Full thread

This is all true.

However, I can't take a stack seriously as an enterprise or production ready piece of software when it does something like iterate a list recursively in performance sensitive code. It's just bizarre. JS doesn't have tail call optimization and for loops are just fine. Being able to blow out the JS stack by having 'too many handlers' is terrifying to me, especially because JS runtimes have catastrophically poor support for handling and debugging stack overflows.

The use of a single array for handlers that can contain multiple items also feels like an architectural red flag to me, but I can understand how that would happen since JS's standard library is so anemic and lacks useful data structures. What you really want is a set (or ordered set, if handler order is super important - it probably is here)

I saw a number of entries in those flame charts that appeared to be V8 compilation internals, which is suspicious to me. But those are probably just debugger/symbol resolution issues, I hope, and not actual JIT recompilation constantly happening during route dispatch? (If v8 were compiling code constantly during dispatch, that would certainly explain multiple-ms pauses...)

> However, I can't take a stack seriously as an enterprise or production ready piece of software when it does something like iterate a list recursively in performance sensitive code. It's just bizarre.

Which is why open source is so beautiful -- someone who is "more serious" can come along, download the source, rewrite that functionality and submit a fork request.

Yep, I think both parties are sort of in the wrong. It's silly how Express currently handles routes, and it's silly of the Netflix engineer to suggest that they should use maps instead.

> JS doesn't have tail call optimization and for loops are just fine.

Not personally familiar with Express's internals, but if this is async iteration nothing's pushing onto the call stack in the first place. Unless you're using generators, but in that case you can just use a for loop.

The deeply nested stack in the flame chart suggests that it is recursing, and the netflix article said it's recursing...

> However, I can't take a stack seriously as an enterprise or production ready piece of software when it does something like iterate a list recursively in performance sensitive code. It's just bizarre. JS doesn't have tail call optimization and for loops are just fine.

Can you explain how you would do asynchronous tasks in series without recursion? For loops successfully handle this when either the tasks are synchronous or can be run in parallel. Neither of those are true here.

Virtually all real-world stacks I know of use a work queue where each element in the list is queued up once it's ready. You don't need on-stack recursion or unbounded memory to track the execution states.

It's pretty trivial to implement this given a promises API and any sort of event queue, but you could also just do it with callbacks. So in the browser you'd literally just use setTimeout.

One reason this is so common is that it's trivial to end up blowing out the stack with recursive IO callbacks, because sometimes all your read()s complete instantly because all the data's in cache. Oops!

How would you handle their problem?

Maybe this can turn into a chance to write some code (I'm willing to) to improve express?

See this post for an explanation: https://news.ycombinator.com/item?id=8632604

The 'push ready callbacks onto a queue' model is really common and relatively straightforward to optimize. I've used it in a variety of applications and it can provide very good throughput in both single and multiple threaded scenarios.

I did read that comment of yours, to make it more concrete --

1. Create some sort of handler execution queue

2. Push first handler onto queue

3. When a handler runs, which may translate into the firing of another handler/ translation of the route, push a "handle callback" (for lack of a better term) onto the queue

4. Return to #3 and continue forever (which is a possibility) or run out of handlers at some point (be done)

Yes.

Most robust implementations have a limit on how long they will pump the queue instead of continuing forever - in most of my applications I cap it at somewhere around 1-10ms. You'd want a shorter limit for realtime stuff like games, a higher limit for high-throughput scenarios like servers. When the limit is reached I yield to the event loop and then continue running handlers from the queue after that.

Reply on news.ycombinator.com