Why is node.js faster than LC server?

[Richard Gaskin]

Andre Garzia wrote:

 > On Mon, Dec 4, 2017 at 3:13 PM, Richard Gaskin via use-livecode wrote:
...
 >> I don't even think we'd need tsNet for that.  Sockets should suffice
 >> for communicating between backend services, and using the "with
 >> messages" option makes them async; indeed that single-threaded
 >> message-driven approach is a big part of what makes Node.js so
 >> performant, offloading as much as practical from the process thread
 >> to the OS.
...
 > IMHO opinions it is not fair to compar NodeJS and LC Server on merits
 > of performance because they are really different beasts...
...
 > All this changes both inside the language itself and on top of it
 > in form of syntatic sugar serves one purpose only, give the developer
 > good ergonomics while keeping the code asynchronous/non-blocking.
 >
 > LiveCode is not an asynchronous language. It has some APIs that work
 > asynchronously when we want them to, but it is not a non-blocking
 > engine.

The stylistic differences, and their implications in implementation, is 
indeed important.  Thanks for that outline.

Google's massive investment in JS will be hard to match for anyone 
seeking to deliver equivalent systems.

Which leaves us asking:  When you want something like Nide.js, why not 
just use Node.js?



 > All our "PUT URLs" calls are blocking...

Take a second look at the original libURL code.  IIRC, in the course of 
exploring some other issues in which what I wanted was truly sync 
behavior but finding it difficult to actually achieve it, it seems 
libURL is using the "with messages" option for socket calls, and where 
sync is needed that's emulated within an async socket method.

Not sure why, and I've been tempted to write my own HTTP client code 
just to make sure I get truly sync behavior when I need it (hoping I'll 
find a way to get that with tsNet once I get back to that problem).

But if it's of interest, take a gander at libURL and let me know if I've 
overlooked something.  If nothing else I'll finally have the true sync 
behavior I'm looking for.  But we may also find that socket comms in LC, 
when using the "with messages" option, use callbacks in a way that 
efficiently leverages OS integration.

Of course this alone doesn't put LC on par with Node.js, for all the 
reasons you noted.  But it does potentially offer opportunities for 
reasonably efficient socket comms, which may be esp. useful on backends 
where all we need are sockets, not necessarily encumbered with also 
supporting HTTP on top.


 > Your original email about scaling anything to millions of users
 > doesn't outline some needs of working at that scale.

If I ever wrote that I was drunk.  But I don't recall writing that; it's 
not consistent with my thinking.  I've done enough testing on the C10k 
problem to be well aware of the challenges of attempting C10m.

When big systems are needed, big ecosystems help.  As a 
right-tool-for-the-right-job kinda guy, I generally advocate industry 
standards for such things.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com