Replies: 5 comments 22 replies
-
|
You are not the first one to ask, but IMHO the usefulness of the project is greatly diminished by losing those. If it was just some ifdefs I wouldn't mind supporting it, the problem is that the JS bundle also needs adjusting because the REPL stores its history in sqlite, localStorage is backed by it, etc. |
Beta Was this translation helpful? Give feedback.
-
|
update: with these changes in git submodule lib/events-lib/libuv/libuv.c these TIMEOUT errors (from post above) are gone .patch for libuv.clib/event-libs/libuv/libuv.c | 46 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
--- Changes ---
lib/event-libs/libuv/libuv.c
@@ -491,6 +491,12 @@ elops_close_handle_manually_uv(struct lws *wsi)
+static void
+lws_uv_close_cb_free(uv_handle_t *handle)
+{
+ lws_free(handle);
+}
+
static int
elops_accept_uv(struct lws *wsi)
{
@@ -507,6 +513,17 @@ elops_accept_uv(struct lws *wsi)
+ /*
+ * If this wsi already has a poll handle (e.g. the underlying fd
+ * was replaced), close the old one so it doesn't leak.
+ */
+ if (w_read->pwatcher) {
+ uv_poll_stop(w_read->pwatcher);
+ uv_close((uv_handle_t *)w_read->pwatcher,
+ lws_uv_close_cb_free);
+ ptpriv->extant_handles--;
+ }
+
w_read->pwatcher = lws_malloc(sizeof(*w_read->pwatcher), "uvh");
if (!w_read->pwatcher)
return -1;
@@ -528,6 +545,15 @@ elops_accept_uv(struct lws *wsi)
+ /*
+ * When using a foreign event loop, unref all lws-internal poll
+ * handles so they never prevent the loop from exiting. The
+ * embedder is responsible for keeping the loop alive while
+ * connections are in flight (e.g. via a separate async handle).
+ */
+ if (pt->event_loop_foreign)
+ uv_unref((uv_handle_t *)w_read->pwatcher);
+
ptpriv->extant_handles++;
lwsl_wsi_debug(wsi, "thr %d: sa left %d: dyn left: %d",
@@ -748,6 +774,8 @@ elops_init_pt_uv(struct lws_context *context, void *_loop, int tsi)
+ if (pt->event_loop_foreign)
+ uv_unref((uv_handle_t *)&ptpriv->idle);
ns = LWS_ARRAY_SIZE(sigs);
if (lws_check_opt(context->options,
@@ -782,6 +810,8 @@ elops_init_pt_uv(struct lws_context *context, void *_loop, int tsi)
+ if (pt->event_loop_foreign)
+ uv_unref((uv_handle_t *)&ptpriv->sultimer);
return status;
}
@@ -889,6 +919,22 @@ lws_libuv_closehandle(struct lws *wsi)
+/*
+ * Called by the embedder after lws_vhost_destroy() to ensure any 0-second
+ * suls inserted for remaining WSIs are serviced on the next event loop
+ * iteration. Without this the idle handle may be stopped, leaving those suls
+ * orphaned and count_bound_wsi stuck > 0.
+ */
+void
+lws_libuv_kick_idle(struct lws_context *ctx)
+{
+ struct lws_context_per_thread *pt = &ctx->pt[0];
+ struct lws_pt_eventlibs_libuv *ptpriv = pt_to_priv_uv(pt);
+
+ if (ptpriv && ptpriv->io_loop)
+ uv_idle_start(&ptpriv->idle, lws_uv_idle);
+}
+
static int
elops_foreign_thread_uv(struct lws_context *cx, int tsi)
{
+46 -0claude explanation:All tests pass. Here's a summary of what was found and fixed: Root cause: server.close() was hanging in BUILD_WITH_TLS=OFF builds because the LWS libuv idle handle had stopped before server.close() was called. When lws_vhost_destroy then called lws_wsi_close(listen_wsi, LWS_TO_KILL_ASYNC), it inserted a 0-second sorted-usec-list timer (sul) for the listen WSI, but nobody restarted the idle to service it. With the sul orphaned, count_bound_wsi never reached 0, LWS_CALLBACK_PROTOCOL_DESTROY never fired, and the JS await server.close() promise hung forever. The bug affected both builds, but was narrower in the TLS build — TLS initialization suls kept the idle alive slightly longer, allowing the framing/keepalive/chunked tests to squeak through the window. With LWS_WITH_TLS=OFF, that window closed and all 5 tests timed out. Fix (3 files): deps/libwebsockets/lib/event-libs/libuv/libuv.c — added lws_libuv_kick_idle() which calls uv_idle_start on the LWS idle handle so it processes any pending suls on the next loop iteration. src/private.h — declared lws_libuv_kick_idle. src/httpserver.c — calls lws_libuv_kick_idle(lws_ctx) immediately after lws_vhost_destroy() so the LWS idle is always running when close suls are inserted. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah the lws integration with libuv is not great, I already had to patch as you have probably seen. |
Beta Was this translation helpful? Give feedback.
-
|
I tried to create custom release with |
Beta Was this translation helpful? Give feedback.
-
|
Actually that's not too bad! I'll take a closer look maybe next week. Thanks for doing all that work! |
Beta Was this translation helpful? Give feedback.
-
|
I have prepared my branch for PR, later today maybe I will create a PR. I plan to add couple of small changes to make it better. But only for build changes, without changes in //udpate: initial draft PR is out: #962 //update#2 (2026-06-07): I tested my smallest (2.1MB) tjs version for my project/use-case and it's working! 💪 I haven't noticed any issues so far. |
Beta Was this translation helpful? Give feedback.
-
|
hi! this seems to be closely related: #514 |
Beta Was this translation helpful? Give feedback.
-
|
I tried quickly some benchmarks, I just wanted to see comparisons of various builds (based on my draft PR #962): Target machine of record: macOS arm64, Apple M1, 8 cores, Apple clang 21, Unix Makefiles/Ninja. Build configurationsBaseline
All configs also inherit Binary size
Startup latency (warm)
Runtime throughput
Throughput is min-ms (lower=faster) except octane (score, higher=better) and Score/MB (octane per binary MB, higher=more efficient). Δ% vs full (negative ms = faster; negative octane = slower):
Peak RSS (throughput workload)
|
Beta Was this translation helpful? Give feedback.
-
|
cool! I'm just a lilbit worried about #514 - looks like kind of mutual exclusion with this 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to do simple changes allowing to make compiled binary smaller. So far I don't have good and big overview of whole txiki.js project. I just get familiar with some parts of build and how features / modules like wasm are included. #514 seems too complicated to me |
Beta Was this translation helpful? Give feedback.
-
|
Fable found another interesting finding how to reduce compiled file size. With it we should get under 2 MB (for macOS). 1. Deduplicate the CA bundle — ~220 KiB, zero risk
bloaty attributes 439 KiB to Fix: move the definition into a new Touch points: 3. Compress the CA bundle with miniz — ~100–110 KiB (after 1.)miniz is linked unconditionally (lws is built with
I will not include it into my PR #962 since I think it's already quite a big. |
Beta Was this translation helpful? Give feedback.
-
|
Oh nice one! That can be a separate PR indeed. |
Beta Was this translation helpful? Give feedback.
-
|
with this build: cmake -B build-smallest \
-DCMAKE_BUILD_TYPE=MinSizeRel \
-DBUILD_WITH_WASM=OFF \
-DBUILD_WITH_SQLITE=OFF \
-DBUILD_WITH_TLS=OFF \
-DBUILD_WITH_FFI=OFF \
-DBUILD_WITH_MIMALLOC=OFF \
-DBUILD_WITH_OZ=ON \
-DBUILD_WITH_LTO=ON \
-DBUILD_WITH_GC_SECTIONS=ON \
-DBUILD_WITH_HIDDEN_VISIBILITY=ON \
-DBUILD_WITH_ICF=ON \
-DBUILD_WITH_STRIP=ON \
-DBUILD_WITH_NO_UNWIND_TABLES=ON
cmake --build build-smallest
outpus size for me (on macOS) is 1,8 MB % du -h build*/tjs | sort
1.8M build-smallest/tjs
5.7M build/tjs |
Beta Was this translation helpful? Give feedback.
-
|
yeah, I'm aware. I just wanted to know how big (I mean small) will be compiled binary with all possible (mostly) cmake options. |
Beta Was this translation helpful? Give feedback.
-
btw why embed it if we could use LD_PRELOAD ? for simplicity ?.. |
Beta Was this translation helpful? Give feedback.
-
|
Yep. There was a 10%+ perf boost, so that was an easy trade off. And it guarantees it works in all platforms without needing to do anything specific. |
Beta Was this translation helpful? Give feedback.
-
|
I'm on 1.6 MB tjs with my additional custom build edits and it's working with my use case (simple app I'm creating). details[tasks."build:smallest-compressed-with-ffi"]
description = "Smallest binary + slim CLI + compressed bytecode (miniz, -z)"
run = """
SLIM_DEFINES="--define:__TJS_EVAL__=false --define:__TJS_SERVE__=false \
--define:__TJS_BUNDLER__=false --define:__TJS_TEST_RUNNER__=false \
--define:__TJS_COMPILE__=true --define:__TJS_APP__=false \
--define:__TJS_HELP__=false --define:__TJS_TLS_CA__=false"
# Regenerate ALL bundles via the DEFAULT build/ toolchain: slim CLI gating
# (esbuild defines on run-main) + -z compression (tjsc). Must use build/ (not the
# smallest dir): `make` re-runs its CMakeCache rule with Release/MIMALLOC defaults,
# which would clobber the MinSizeRel config below if pointed at it.
make -B core stdlib RUN_MAIN_DEFINES="$SLIM_DEFINES" TJSC_COMPRESS=-z
cmake -B build-smallest-compressed-ffi \
-DCMAKE_BUILD_TYPE=MinSizeRel \
-DBUILD_WITH_WASM=OFF \
-DBUILD_WITH_SQLITE=OFF \
-DBUILD_WITH_TLS=OFF \
-DBUILD_WITH_FFI=ON \
-DBUILD_WITH_MIMALLOC=OFF \
-DBUILD_WITH_OZ=ON \
-DBUILD_WITH_LTO=ON \
-DBUILD_WITH_GC_SECTIONS=ON \
-DBUILD_WITH_HIDDEN_VISIBILITY=ON \
-DBUILD_WITH_ICF=ON \
-DBUILD_WITH_STRIP=ON \
-DBUILD_WITH_NO_UNWIND_TABLES=ON \
-DBUILD_WITH_COMPRESSED_BYTECODE=ON \
-DCMAKE_C_FLAGS="-DTJS_NO_TLS_CA"
cmake --build build-smallest-compressed-ffi
# Restore full-CLI uncompressed bundles so a plain make / other build dirs work.
make -B core stdlib
echo "Build size: $(du -h build-smallest-compressed/tjs | cut -f1)"
ls -lh build-smallest-compressed/tjs
"""lm@♥ txiki.js % ls -l ./build-smallest*/tjs
-rwxr-xr-x@ 1 lm staff 1667504 Jun 18 13:26 ./build-smallest-compressed-ffi/tjs
-rwxrwxr-x@ 1 lm staff 1649616 Jun 18 12:41 ./build-smallest-compressed/tjs
-rwxrwxr-x@ 1 lm staff 1864256 Jun 17 23:16 ./build-smallest/tjs
lm@♥ txiki.js % du -h -d 1 ./build-smallest*/tjs
1.6M ./build-smallest-compressed-ffi/tjs
1.6M ./build-smallest-compressed/tjs
1.8M ./build-smallest/tjs |
Beta Was this translation helpful? Give feedback.
-
|
Impressive! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I had an idea to make tjs even smaller :) So I asked AI for help and it creates one .patch file to apply and then
make.The patch did exclude
sqliteandwasm... and it works for me.Maybe someone (like me) desn't need bundled
sqliteandwasm. Smaller binary size means faster cold start, right? I didn't measured it. But I like this idea to have very lightweight version of txiki.jsthe final compiled binary
tjsreduced from 6,4MB to 4MB.here is the patch (click to expand it):
applied using:
git apply "${patchFile}"//update:
This solution is rough POC and probably not widely usable, just some example working for me and maybe some reference or starting point for others.
I don't know how to achieve it in more intuitive way.
I don't expect it should be supported in core txiki.js, I just wanted to share an idea and how make already lightweight JS runtime even more lightweight :)
Beta Was this translation helpful? Give feedback.
All reactions