Slow Storyline Publishing Speed

Storyline 360 is an excellent piece of software. Combining quite complex feature sets in a relatively easy to use way, in a UX that feels familiar ...... but I think we need to face it..... there is definitely at least one big piece of Storyline which we all have to stare straight into the face of, each time we hit that publish button!

Yep, that wonderful little blue progress bar. And as I sit staring at it - trying to push it faster forward with a combination of The Force, Prayer, and mental willpower, I fear I am left with only one conclusion.  Storyline performs like an asthmatic sloth trying to swim through treacle!! Thats right; it can be slow, slow, painfully slow!

Lets take the worst offender - publishing "large" courses (if 96 slides can even be considered large these days). On a benchmark test, I recorded just over 4 minutes to publish a standard course of 96 slides (audio on every one).

Having read the "4 minutes" above, you may be ready to dismiss my post immediately by saying "Only 4 minutes? Thats great! Stop complaining, its only 4 minutes".

However, this is my professional livelihood - I am a freelance eLearning developer. So, take that 4 minutes, and multiply it many times over - from publishing the same course multiple times per day (for testing, changes from the client, bugs in Storyline output) and then factor in multiple courses across multiple clients.... and the time spent staring at a publishing screen starts to mount up quickly!

 

So I would like to ask the Storyline 360 Dev Team for some information to help the community work "under the hood" to improve our beloved Sloth athlete.

Digging around on my system, I notice straight away that Storyline does alot of weird things with caching previously published audio/video - eg. the AppData working directory has literally 100 x Gb's of "tmp" files bloating out the main drive. Are these where the cache resides? If not, where is Storyline making the decision to "encode" audio/video from because its obviously making a judgement call from some previously published assets. Watching what happens to the filesystem when publishing is taking place is interesting, but the real working is very much hidden from the user.

To try to get more information about what is causing this severe bottleneck, I fired up my system sensors and when Storyline is publishing, I can see no drain on CPU CORES, THREADS, DRAM, VMem, or even SSD. All sit around 3%-20% usage. It doesnt even look like Storyline is agressively r/w any of the drives or requesting VMem access?!

Following on from this, I then "tweaked" the 32bit Storyline executible so that it could step beyond the 2Gb memory limit of 32bit applications. This now lets Storyline use up to 4Gb, and yet here I observed only a very small increase in publishing speed (about 20 seconds from the previous benchmark)

So Dev Team, can you please shed some light on what Storyline is doing which takes the time? This is not a criticism, merely a request to work alongside your customers and their development needs, and help us understand if there is anything we can do.

Finally, can I ask if a 64bit version of Storyline 360 is even on the horizon? I can see by the Storyline Features Roadmap that it is not mentioned. This is a bit disappointing in 2020, and I hope it hasnt been overlooked because of the belief that everyone will be developing in Rise - because all my clients use Storyline, and have no desire to migrate (despite me evangelising the benefits of truly responsive eLearning!) and 90% of my work right now is very much Storyline - a fact not likely to change for a good number of years to come.

Expectantly.... 

Andrew  (and "Flash Flash 100-yard Dash") :)