Tiny devices

[mcollina]

It seems libuv runs only on unixes and Windows. Are you still aiming at small devices running these operating systems (say OpenWRT), or are you aiming also at embedded devices?

Anyway, I'm in. I see a big potential in this!

[creationix]

By tiny, I mean things like arm linux boxes with ~128mb of ram. These things can run node, but not well and not many instances.

It would be cool if we could run on things like my $10 TP-Link router I picked up in China. These devices have a slow MIPS cpu, tiny flash drives and around 8-16mb of ram running a minimal linux. I've seen them run lua so I expect they can run duktape. I'm not sure what it would take to get libuv on them.

[dominictarr]

how heavy is libuv? there isn't that much code... and it doesn't manage memory for you. I don't really see how it would require headroom that 8mb doesn't have, provided that you used an allocator that made sense in low mem.

[creationix]

It's not too heavy. Luvit which includes luajit + libuv + openssl + zlib + node API shims written in lua clocks in at around 1.5MB (vs about 11mb for node)

[creationix]

Stock lua + libuv (luv bindings) loads a repl at 1mb rss.

[creationix]

For comparison, the stock lua repl included in lua is 1.1mb. So libuv is more efficient than whatever is baked into lua.

[creationix]

@mcollina I don't think I'm even going to attempt to run libuv and a JavaScript runtime on a microcontroller. Is there prior art in this kind of experiment?

[dominictarr]

espriuno has a very low mem js runtime, but it is very slow (trades mem for cpu) it evals it as it parses it, i understand, instead of building an ast etc. of course, in a microcontroler you arn't gonna have a kernel so a polyfil for posix doesn't make sense anyway.

[svaarala]

Duktape runs on embedded devices with 128 kB RAM right now (hello world RAM footprint is around 80 kB), and there's ongoing effort to get the hello world footprint lower. An event loop is often needed for these environments too, but only a very bare bone one: timers, and perhaps some networking. I think that a separate event loop library for these very tight environments makes sense, while DukLuv would work well for environments with at least a few megabytes of memory.

[creationix]

@svaarala wow, that's really impressive! How does that compare to stock lua and embedded lua?

You're right that libuv is way too much for that kind of device, but it sure is nice and provides a lot of primitives for devices that can run it.

[prust]

Sorry to comment on an old thread, but have you looked at mbed TLS (formerly PolarSSL -- libcurl supports compiling with it) as a lightweight alternative to OpenSSL and miniz (github) as a lightweight alternative to zlib?

There are times when it would be nice to have the full node.js API, but there are other times when I would prefer a small, self-contained executable with just the pieces I need (even avoiding libuv when it isn't necessary).

[creationix]

Thanks for the links. I'm actually using miniz for luvit.io (with a few patches I added to fix it's buggy zip file support.) We're still using openssl, but I think switching to mbed would shrink the binary a bit. I'll look into doing the same for dukluv when I get back to working on this.

[prust]

@creationix: Great! Are the patches included in https://github.com/creationix/dukluv/blob/master/lib/miniz.c ?

[prust]

Follow-up: it looks like the CRC patch (https://github.com/luvit/luvi/issues/113) is included in dukluv's copy of miniz.

[creationix]

Right, when in doubt, look at luvit's miniz code, I try to copy all patches here, but sometimes forget.