I am using the following pg and trying to identify why there is a long time from fetching the data and when it is finally displayed especially on the second time loading through when it is from disk cache.
The last xhr call finishes after 1 second in the network panel, but it takes an additional 40 seconds to load before the scene is interactive.
If you could point me in the right direction for getting that time lower that would be awesome!
Hi @bscott711
Your code looks good to me. The e2e loading time goes down more or less linearly if I reduce numFiles size.
let numFiles = 99;
So I guess the latency is inevitable for processing glb files and building up the geometries. Chrome dev tool profiling shows lots of time spent on _updateExtend, createIndexBuffer, refershBoundingInfo, etc.
A side note. Babylon already has an async version of LoadAssetContainer that returns a promise. You don’t need to promisify it yourself. Instead you can write something like the following:
let assets = scenes.map(file => BABYLON.SceneLoader.LoadAssetContainerAsync(scenes_root, file, scene));
let assetContainers = await Promise.all(assets);
BTW, just out of curiosity, do you mind telling what are those models. 
Thanks for taking a look at profiling.
As far as the models go, those are actual data generated on a microscope, and the renderings created in chimeraX. We are watching a white blood cell eat a target cell that has been coated with a therapuetic antibody. The idea behind this is to be able to embed it in manuscripts online to have interactivity
I skipped the idle time in my last reply. The profile result ~40s composes two major parts.The scripting time and idle time each take about 20s. There are lots of small fragments of idle times. I don’t know the actual implementation in babylonjs. My wild guess is the asset loading can take some time. So I assume babylon.js uses recursive setTimeout to break lengthy process to small chunks of js calls, and allow the rendering loop to process. Thus, it avoids blocking the main js event loop for too long. But it also introduces these small fragments of idle time.
If my guess is correct and if you don’t mind UI is frozen, it should be possible to let js code to busy processing assets for 20 seconds and then give back the main process to rendering. Thus, the scene should be ready after only 20s instead of 40s in your scenario. But I don’t know if babylon.js supports such config.
@Deltakosh Could you help on this?
It turns out I was doing something silly and creating a second rootnode when trying to simply rotate the current rootnode. Using your suggestion of the async I was able to get it down to 25 seconds for loading. So getting better, and I would definitely be ok with the ui being frozen for half the time, as it currently is frozen the entire time haha
https://playground.babylonjs.com/#C8GA64#15