You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Asynchronous API for single threaded language have proven to be pretty efficient and fast, it's what has leaded node.js to a big success.
So, maybe it would be better tu use luvit as a core lua engine, for using asynchronous APIs (file, network, etc.) rather than current synchronous ones ?
I guess it would hugely simplify and lighten the code, and, at the sime time, able to provide a better performing tool for ROS.
The text was updated successfully, but these errors were encountered:
Looks like an interesting thing to try out. But I'd use it only as an optional add-on to keep the external dependencies of roslua at a minimum. Last summer I vastly improved its performance while at SRI and now it's pretty good in my current scenarios. Most critical in terms of performance is message deserialization rather than network throughput. Any specific scenario where network performance of roslua has been the bottleneck?
I'd happily try out patches you might provide that add optional support for luvit, e.g. automatically use it if available and not explicitly disabled with an init parameter. I have neither the time nor the need to do this myself in the foreseeable future.
@timn @creationix
Asynchronous API for single threaded language have proven to be pretty efficient and fast, it's what has leaded node.js to a big success.
So, maybe it would be better tu use luvit as a core lua engine, for using asynchronous APIs (file, network, etc.) rather than current synchronous ones ?
I guess it would hugely simplify and lighten the code, and, at the sime time, able to provide a better performing tool for ROS.
The text was updated successfully, but these errors were encountered: