We are trying to speed up our app load times with multiple models by attempting to load models asynchronously. We use loadSubtreeFromScsFile function to fetch the model and retrieve the Hoops ID that is returned from the promise. After the model is loaded, we then use the Hoops ID to setNodeMatrix on it to place it in position.
Currently, we do this synchronously, loading one model at a time and setting its matrix from a stored value. When I attempt to do this asynchronously, loading times don’t seem to change at all. In the network tab of chrome I can see that
Am I being bottle-necked by Hoops Communicator loadSubtreeFromScsFile?
Even though the sync way is shorter in time, the requests are one after the other. With async way, the requests take longer but run in parallel. At the end of testing, I get the same load time results, down to the same second (even with 100+ models being loaded)
In the current implementation parsing the scs data loaded with loadSubtreefromScs file is a largely synchronous operation, meaning that “under the hood” loadSubtree calls are queued and processed one after another (we could be using webworkers to improve this behavior but that is currently not the case). The actual fetching of the files from the server should still happen asynchronously, though I think there is a limit on how many fetch operations will are allowed to be processed at a time imposed by the browser. As the scs files are seemingly already cached in the browser in your case, the actual loading part is negligible which is why you are not seeing any overall performance improvements.
One thing you could try, is using the loadsubtreefromscsbuffer function, which gives you control over the actual fetch operations. Other partners are using this function to prefetch models and/or to implement more advanced caching schemes using the browsers storage API’s. In the scenario above I don’t think you will see a tangible improvement though.
One thing I want to point out that is maybe not obvious is that loadSubtreeFromScsFile/buffer does not keep track of scs data that has already been loaded, so if you need the same file more than once (e.g. it is an instanced part), it will be redownloaded and its geometry is copied. To improve that, you could build an xml description of the models you want to load first, and then use that to handle the loading via loadsubtreefromxmlbuffer. In that case, all referenced models are instanced if they show up more than once, which means they don’t need to be redownloaded and parsed again, and don’t take up additional memory.
Thank you for the insight! We have already implemented a way to re-use models without needing to re-download the same SCS file, so we are good on that end.
loadSubtree being a synchronous operation “under the hood” makes sense why cached files seemingly load at the speed as synchronously or asynchronously.
I did a few more tests by disabling the browser cache and we did in fact gain a speed boost in loading times (which makes sense, since multiple SCS files become queued and download at the same time).