Why is node.js faster than LC server?

[Richard Gaskin]

jonathandlynch wrote:

 > Thinking about this further...
 >
 > Could we set up LiveCode to run on a VPS, so it is always live and
 > listening to a port. When a request comes in, it would use TSnet to
 > send an asynchronous request to a local database. When TSnet gets the
 > callback, it passes the data back to LC, which processes it and passes
 > the information to the user through the port.
 >
 > This would always be asynchronous and thus never get hung up waiting
 > for a long request. It seems like it could be quite fast. Would that
 > work?

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.

A while back Pierre Sahores posted some benchmarks here related to these 
sorts of explorations, generally quite flattering to LC.  Of course the 
LC engine is made by a small team in Edinburgh while JS has millions opf 
$ invested from some of the largest companies in the world, so we may 
want to temper expectations of comparative performance accordingly.  But 
for a wide range of workloads, LC-based daemons can work well with 
backend services, at least much more efficiently than relying on the CGI 
model.

The bigger question re. LC on the backend is perhaps why we're having 
this discussion at all:  if performance is critical enough for us to 
work out LC daemons from scratch, why not just use an existing toolkit 
for that work and enjoy the advantages of a large ecosystem of prefab 
solutions?

And that's the chickens-and-eggs of this:  until we have such a large 
community of prefabs the cost-effectiveness will continue to favor 
current leaders, but without someone starting such an effort we have 
little choice but to use current leaders and thus it becomes a 
self-fulfilling prophecy.

Software evangelism is tricky business.  And when building business 
infrastructure, our responsibility to the company owners requires us to 
ask whether evangelizing a personal favorite language is a higher 
priority than delivering a cost-effective robust solution ASAP.

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