async-load-fn PARALLEL loading

[awb99]

Is your feature request related to a problem? Please describe.

I am extensively using the async-load-fn in the browser. It works pretty much perfect! When the webserver
that provides sends either modules or sci source code to the browser is in a local network, this process
is fast and works perfectly. However, when the server is far away, then there is a significant wait time.
This wait time is basically the roundtrip-time to the server multiplied by the number of namespaces that
are async loaded. This is because sci loads the libspecs one by one.
When there are say 20 namespaces that are required that need to be loaded via the async-load-fn then
when the server is far away, there are 20* 200ms load-time = 4 seconds.

Describe the solution you'd like
Sci sends out all the async-load-fn requests at the same time, and then just starts compilation once all
promises have been fulfilled.

Describe alternatives you've considered
My app uses multiple modules; this modules are finetuned, so only large modules (>100kB) get moved into their
own modules; smaller modules I moved to the main bundle. Where the roundtrip-time accumulation time is high, is
when the web app uses a lot of sci namespaces that are all very small, and the only reason to have multiple
namespaces is for a clearer code organization. I am considering bundling multiple sci namespaces to bundles of
namespaces, so that the async-load-fn does not trigger a fetch request that gets sent to the server that often.

[borkdude]

Sounds like something that might cause multiple request for the same namespace as one namespace might load another one. This is why they are loaded in order (same as in Clojure on the JVM for example).

[borkdude]

Btw feel free to poke around in sci/async.cljs if you wish.

[awb99]

sci loads each namespace that has not been loaded ONCE. This works fine. Say I want to render a page, that should
get lazy-loaded because it will require lots of render-functions that are huge (vega, highcharts, aggrid, etc). So I put
the page into its own namespace, and all the render-functions are in the ns requires. Typically I also would add 5-10
namespaces that are written in interpreted sci clojure. Utility functions, etc. So this would require then say 10 namespaces,
and the requiring process is SERIAL. So it would first asynchronously require the first namespace in the (:require) list.
Then it would require the second namespace, etc. If there are 10 such namespaces, and the roundtrip time to the server
is 200ms, then this means I need 2 seconds to load that page.

[borkdude]

sci loads each namespace that has not been loaded ONCE. This works fine.

Currently, yes, exactly BECAUSE requires are serialized.

[borkdude]

then this means I need 2 seconds to load that page

Normally responses from servers can be cached though so after caching it should load very quickly.

[awb99]

The server is replying FAST. This is not the issue. The issue is that sci sends one request, then waits for the answer. The the next request, then wait for the second request, etc. What kills me is the ROUNDTRIP time to the server. If sci would send
all the async-load-fn request AT ONCE, then in 200ms all requests are processed. But if say 10 ns requests are send one after
another, then the wait time is 10*200ms = 2 seconds.

[awb99]

Perhaps I should elaborate a little bit how I use sci. So I use shadow-cljs for clojurescript modules that get compiled into js bundle (or separate js modules if they are big). I expose to the sci context all namespaces of compiled clojurescript with the same
name as they are in clojurescript. You do it the same way with sci-configs. This has a huge advantage: one can develop apps in only interpreted sci clojure(script). And if at some point there is enough complexity that warrants compilation with shadow-cljs, then it is very easy to change it so that this namespaces instead of being interpreted by sci are compiled by shadow-cljs. The big advantage of using sci is (other than it allows users to extend the website at runtime in a dynamic fashion) that the lazy-loading of compiled cljs-js-bundles is completely transparent to the user. But the flipside is that the (ns (:require)) can become big.

[awb99]

sci async-load-fn:
https://github.com/pink-gorilla/goldly/tree/master/goldly/src/goldly/sci/loader
I load lazy-shadow-cljs-modules and sci-cljs-sources that get interpreted.

[borkdude]

The server is replying FAST. This is not the issue.

This is not the point. If responses of assets (.js files) are cached, a request shouldn't even take a 1 millisecond. It seems you should fix that problem first.

As I said, feel free to explore parallel loading, the code is in sci/async.cljs but I don't think it's actually a great idea and I have the feeling that it could create issues. What could for example happen:

(ns a (:require [foo] [bar] [baz]))

(ns foo (:require [bar] [baz]))

For namespace a we get three parallel requests, requesting foo and bar, but as soon as foo comes back, we're also going to request bar and baz. Suppose bar contains top level side effects. We have no way to prevent that side effect from happening multiple times instead of only once. Also you're creating more requests (5) instead of the actual amount necessary (3).

[borkdude]

My point being: you can save yourself a roundtrip to the server if you allow the browser to cache your .js file.

More info e.g. here: https://v8.dev/blog/code-caching-for-devs

[awb99]

The server is always fast. When I run the app on localhost (or on the same lan), I have page load time of milliseconds. This is because
round-trip times are really fast. But when I move the same app to a remote server, then it gets slow. There is nothing in terms of caching that. I can do on the server. What I would need to do is create a cache of all interpreted sci-cljs files and send them in one request to the browser once. I can do that. So then instead of sending one request per namespace to the server, it would serve the namespace source code from a browser based cache.

I read your example. You have a good point! The problem is that the async-load-fn can use scia/eval-string, and that this can trigger further ns requires. You have the loading and the modifying of the context all together.

I guess somewhere you calculate which ns to require. Perhaps this function can be used? Perhaps there can be an event that
gets raised to pre-cache certain ns-s? Then the complexity to use the pre-cache will rest with the async-load-fns.

I do not want to create troubles :-) I am raising this point, because at some point every web-app that uses sci with a lot
of namespaces will run into the same issue. It's just not visible when one is working on localhost or in the same lan.

Thanks a lot for this wonderful project! (And all the others you do!)

[borkdude]

There is nothing in terms of caching that. I can do on the server.

You need to allow the browser to cache the result. Then the browser won't even go to your server.
You may need to tweak the headers you send back with your .js files, perhaps you disabled caching for those.
Please read the link I sent: https://v8.dev/blog/code-caching-for-devs

[borkdude]

Also perhaps it depends on which web client you're using in the browser, but fetch (the built-in one) should behave normally with respect to caching.

[borkdude]

Also see https://developer.mozilla.org/en-US/docs/Web/API/Request/cache

[awb99]

The browser cache idea is a great one. So I just really need to request all sci cljs files on startup once, and then most likely
further requests would be served from the browser cache. I will investigate this! Great idea!

[borkdude]

Yes, but even if you do not do this, once you have used your application, and you will do so 30 days later, the responses will still be cached. It does depend on headers that your server sends back though. If you need to evict the cache, often people use unique names/shas in the .js file's name. shadow-cljs has an option for this as well.

[awb99]

Great ideas! Thank you! I am using ths feature of shadow-cljs. For sci in developer-mode I am currently pushing new source-code
files to the browser if there is a change in the file. I guess I could generate hash codes for each interpreted sci cljs file. And then
this hashes would end up in the fetched url. I need to have more thinking of that. :-)